Kiosk auto-login URL shows the login mask: fix the design key

Why does the kiosk URL land on the login mask instead of the visualization?

The mask appears because the server rejected one of the values. The two that decide it are the design key after cl= and the endpoint. The key must match the string under Project → Design exactly. The endpoint is /hs on version 4.12, /hshtm on older versions.

The tell is that the mask arrives already filled in: user and password were accepted as typed, so re-entering them is not the job. Both failing values are readable on the server itself. The design keys sit under Project → Design, one line per design, and the version is the one the server reports about itself. Fix those two first. The browser and the startup command come later in this page.

Which endpoint does version 4.12 use for the direct call?

On a project that runs on server version 4.12 the direct call goes through /hs. On a project that never left an older version it goes through /hshtm. Both carry the same four parameters behind them: user, pw, cl and ref.

The help prints both templates:

• https://HS-IP/hs?user=BENUTZERNAME&pw=PASSWORT&cl=DES&ref=RRR
• https://HS-IP/hshtm?user=BENUTZERNAME&pw=PASSWORT&cl=DES&ref=RRR

HS-IP is the server's address. DES is the slot for the design key, RRR the slot for the refresh label, and every slot gets a real value from your project. Projects that were created on an older server and pulled up to 4.12 can behave half old and half new; the reason sits with each design's history, and the first FAQ below takes it apart. Matching the server version before you trust an old URL is the same discipline as matching the installed build first in HMI software upgrades.

What exactly goes into the cl= design key?

cl= takes the design key exactly as Project → Design prints it. Every prefix letter, every digit and every trailing letter counts: a panel called with D1920x1080 sat on the filled login mask, and the same panel called with D1920x1080V went straight in.

Real projects use different key forms. A 1920 x 1080 design carries V1920x1080 in one project and D1920x1080V in another, and an old 1366 x 768 design carries its own string. The resolution never gives you the key; only Project → Design does. Open the list, read the key of the design the kiosk should show, and copy it into cl= character for character. This is also why the drop-down on the interactive login page can work perfectly while the URL fails: the drop-down carries the real keys, and the URL carries whatever was typed into it.

What belongs in ref= when the client is a browser?

ref= takes one of the project's refresh time labels. The label that works for an HTML client out of the box is R3, because R1 and R2 are inactive for HTML clients unless you activate them in the server's refresh times settings.

The seconds behind each label are whatever the project defines. If the project's refresh list gives R3 a 30-second interval, the panel updates every 30 seconds; there is no server default behind it. Fill ref= with a label that is active for HTML; that is the whole job. If the board should update faster or slower, change the interval or the activation in the refresh times list, then put that label into the URL.

How do the symptoms tell you which value is wrong?

Read what the mask shows and where a manual login lands. User and password already filled in point at the design key in cl=. A manual login that opens the old 1366 x 768 design points at the endpoint in the path.

• Mask with user and password pre-filled, one click reaches the design: cl= misses part of the key, usually a trailing letter, D1920x1080 for D1920x1080V.
• Mask with the template words still in place: the URL still says cl=DES or ref=RRR. Those are slots in the help's template, and each needs your real design key and refresh label.
• Mask, and after a manual login the old 1366 x 768 design appears although the kiosk should show 1920 x 1080: the call is on /hshtm of a project now running 4.12, and the new design does not come up through that path.
• Mask no matter what, but the interactive login page lists both designs and logs into both: designs and credentials are fine; the URL parameters are the part to fix.
• The same URL opens the old 1366 x 768 design directly but not the 1920 x 1080 one: the two designs carry different keys, and the new one needs its complete string and the new endpoint.

Worked example: a 1920 x 1080 design on version 4.12

Take a 4.12 project whose design key under Project → Design reads D1920x1080V and whose R3 label carries a 30-second refresh interval. The working call is https://192.168.1.50/hs?user=kioskuser&pw=kioskpw&cl=D1920x1080V&ref=R3. The same address on /hshtm or with cl=D1920x1080 brings the filled mask back.

Read the four inputs off the server before typing anything:

• Server version 4.12, so the endpoint is /hs.
• Design 1920 x 1080, key under Project → Design D1920x1080V.
• Refresh label active for HTML: R3, carrying a 30-second interval.
• Kiosk user on the server: kioskuser, view rights only.

First attempt, from an old bookmark:

https://192.168.1.50/hshtm?user=kioskuser&pw=kioskpw&cl=D1920x1080&ref=R3

Two values are wrong for this project. The path uses the older /hshtm endpoint, and cl= truncates the key after the digits. The server answers with the login mask, filled in. Change one value at a time: with /hs and the truncated key the mask still appears, which pins the key. Then the complete key:

https://192.168.1.50/hs?user=kioskuser&pw=kioskpw&cl=D1920x1080V&ref=R3

and the browser lands directly in the 1920 x 1080 design with no click, updating every 30 seconds from ref=R3. The check is the absence of the mask; there is nothing else to confirm. Test the call in a normal browser window before anything goes into the panel's startup.

Recommendation: Copy the design key from Project → Design character for character, call a project on version 4.12 through /hs, and fill ref= with R3; keep /hshtm for projects that never left an older version. Test the URL in a normal browser window before it goes into the kiosk startup, and give the kiosk user view rights only.

How do you launch the visualization full screen in the kiosk browser?

The browser does the full screen, not the URL. Start the kiosk browser with its full-screen switch and hand it the working URL:

"C:\Program Files (x86)\Microsoft\Edge\Application\msedge.exe" --kiosk "http://192.168.1.50/hsvisu?user=kioskuser&pw=kioskpw&cl=V1920x1080" --edge-kiosk-type=fullscreen

This form points at /hsvisu, the page whose design drop-down you normally see, with user, pw and cl behind it. On a 4.12 project it opens the 1920 x 1080 design straight in, where the /hshtm call showed the mask. Put the command into the panel's startup and keep the whole URL inside double quotes. The ampersands between the parameters belong to the URL, and an unquoted command line cuts the call at the first one, so the server sees no design key at all. If the design opens but pieces of it render broken, that is a rendering fault, not a login fault; fixing fragmented SVG rendering in a kiosk browser is the page for that side.

How do you keep the panel's login credentials safe?

A direct-call URL carries user and pw in plain text through the command line, the browser history and every bookmark. The account behind them should be a dedicated kiosk user with view rights only, and the visualization should stay off the open internet.

Create that user on the server with rights to look and none to change. On a panel that visitors can touch, weigh once whether skipping the mask is worth credentials sitting on the device. Where it is not, leave the mask and accept the one click. Call the server over HTTPS where it offers it, as the help's URL template does, and keep the endpoint on the building or plant network. If a spot needs a screen that shows content without any server behind it, that is a different class of display; our shop-floor screens section covers the offline-playing kind.

Questions