Enabling camera access in a web application

Checks and troubleshooting

Requesting camera access

If your application needs a camera, contact your software provider. Together, you can check the required settings, and support will enable access for the trusted domain. This is usually a small, quick service adjustment performed by the provider’s support team primarily to protect privacy and keep camera access secure. You do not need to modify program files yourself.

To get started, send the device ID, the application link or domain, and whether you also need a microphone. Support will work with you to gather any further details if needed.

What technical support will do

The service procedure below is intended for the provider’s support team. The required changes depend on the player and JCEF versions. Domain restrictions are a requirement for the resulting solution, not a statement that every installation already supports them.

Retrieving and modifying latest.jar

Support first resolves the actual target of /opt/device/runtime/latest.jar on the device and downloads the JAR currently in use. Support makes a separate backup of the original and records its path, version and checksum. Changes are prepared on the downloaded copy, retaining the working original for rollback.

Updating the player application

Support checks the runtime file /opt/device/runtime/latest.jar and the JCEF version. The player must handle camera permission requests and compare the actual requesting origin against an approved list. An origin consists of the scheme, domain and port. Matching a fragment of text within a URL is insufficient.

Only approved origins may be allowed. Additional subdomains, ports, redirects and embedded pages must be assessed separately. Microphone access is allowed only if the application needs it and the provider has approved it. All other requests must remain denied.

Support uses the permission interface available in the installed JCEF version. If it cannot provide the required control, support prepares a compatible update. The change must not enable automatic access for all websites.

Classes involved in the change

The org/cef/handler/CefAppHandlerAdapter.class class and its onBeforeCommandLineProcessing() method prepare Chromium startup parameters. Support checks and, where necessary, adjusts media-related settings here. This method does not itself make decisions based on the requesting domain, so it cannot be the sole point for implementing access restricted to trusted domains.

Permission decisions require a handler attached to the org.cef.CefClient client. In a compatible JCEF version, this means implementing org.cef.handler.CefPermissionHandler and its onRequestMediaAccessPermission() method. Support adds a custom implementation class, for example TrustedCameraPermissionHandler — this is a proposed name for a new class, not a required existing file. The handler receives the requesting page’s origin and requested access type, checks them against the allowed list and uses the response callback to grant only matching permissions. Other requests must be explicitly denied.

Before implementation, check the actual interfaces in the specific JAR. If CefPermissionHandler is absent, adding a single class is insufficient. Compatible Java bindings and native JCEF libraries, or another verified permission mechanism for that version, are required. Compile modified classes for the matching Java version and package them in the runtime JAR. The module-info.class class does not control camera access and does not need to change solely to enable it.

Operating system permissions

On the device, support checks the camera connection, the relevant /dev/video* device and the account that actually runs the player. Support verifies the camera device’s owner and group.

Command for support:

ls -l /dev/video*

If the camera device belongs to the video group and the player account is not a member, support adds it. The following example applies only after verifying that the account is actually named kiosk.

Command for support:

sudo usermod -aG video kiosk

New group membership takes effect in a new user session or after a restart. Operating system permissions alone do not replace browser permission handling.

Backing up and replacing the file on the device

Before making changes, support resolves the actual target of latest.jar, records the version and makes a separate backup of the original file. Use a new backup name so an earlier backup is not overwritten.

Command for support:

readlink -f /opt/device/runtime/latest.jar

After verifying the changes, support uploads the modified JAR to the same device. During the service window, support stops the player, preserves the original backup and replaces the active version with the modified one, or switches the latest.jar symbolic link to the new version. Support verifies ownership, permissions and checksum. The original file is retained.

Support checks operating system permissions and automatic update behavior, then restarts the player or, if needed, the device and checks the camera in the approved application. If a problem occurs, support restores the backed-up original version.