iPad kiosk clock-in web app shows restricted error and wrong redirectSolved

Participant
Discussion
2 days ago Sep 25, 2026

We have a few iPads enrolled in Hexnode and assigned to the same device group with a kiosk policy and web content filtering policy. They are used only for an employee clock-in/out web app.

The setup used to work on at least one iPad, but it was inconsistent. Sometimes one device would load the company kiosk login correctly, while the others either showed a restricted page or redirected to the personal employee login page instead. Eventually, all iPads started failing at the same time.

The clock-in site keeps the same base URL during login, but after an employee enters their ID, the backend adds a dynamic token/path. We tried moving the allow list between policies and also tried adding another URL, but that did not fully fix it.

What is the right way to configure this in Hexnode so the iPads stay in kiosk mode and the clock-in site works without restricted errors?

Replies (3)

Marked SolutionPending Review
Hexnode Expert
2 days ago Sep 25, 2026
Marked SolutionPending Review

Hi @grace_t ,

For an iPad kiosk web workflow like this, check both the kiosk web app configuration and the iOS browser permissions used by the site.

Recommended checks:

1. Add the correct base URL as a web app in Hexnode

  • Create or edit the web app using the main clock-in URL, for example the base domain used for the company kiosk login.
  • Avoid configuring only a later redirected URL or a tokenized URL, since those dynamic paths can change after login or employee ID entry.

2. Add the web app to the iOS kiosk policy

  • Go to the iOS kiosk policy.
  • Add the newly created web app to the kiosk configuration.
  • If a web clip is also being used, make sure it points to the same correct base URL.

3. Review Web Content Filtering

  • Ensure the required base domain is allowed.
  • If the site redirects between related subdomains or uses additional paths after login, those required domains must also be allowed.
  • Do not rely on allowing only the final tokenized URL.

4. Reassociate or repush the corrected policy to all affected iPads

  • Confirm that all devices are in the intended device group.
  • Make sure the corrected kiosk policy is associated with that group or directly with the devices.

5. Check camera permission on the iPads

  • On each iPad, open iOS Settings and verify that Safari camera access is allowed.
  • If the clock-in workflow uses camera access, denied or unset Safari camera permission can cause repeated prompts, timeout behavior, or failure inside the kiosk web app.

Regards,
Isabel Lora
Hexnode UEM

Marked SolutionPending Review
Participant
2 days ago Sep 25, 2026
Marked SolutionPending Review

That makes sense. In our case, two iPads were also showing a camera permission prompt repeatedly, while one did not. All three devices are the same model and assigned to the same Hexnode group. Would the kiosk policy not force that permission automatically?

Marked SolutionPending Review
Hexnode Expert
2 days ago Sep 25, 2026
Marked SolutionPending Review

On iOS, website camera access is still handled through Safari/WebKit permissions. A kiosk policy can restrict the device to the web app, but it does not always silently grant website camera permission for every site interaction.

If one iPad had previously allowed camera access and another had denied or not yet granted it, they can behave differently even with the same Hexnode policy. That explains why identical devices in the same group may show different camera prompts or timeout behavior.

The practical fix is to check the permission state locally on each iPad:

  1. Open Settings.
  2. Go to Safari or the relevant website permission settings.
  3. Set camera access to Allow for the clock-in site.
  4. Relaunch the kiosk web app and test the scan or camera step again.

After the permission is allowed, the kiosk web app should stop prompting repeatedly and should continue through the clock-in flow.

Regards,
Isabel Lora
Hexnode UEM

Save