Feature Note: Access Control Dialog

The features of Access Control Dialog box is explained in the following topics.

• Feature overview
• Access Control Dialog box
• Delayed User Authorization
• Domain whitelist support
• Language support

Feature overview

This feature is available for the Voice and Video SDK v3.0.1.

The SDK provides a GUI control, Access Control Dialog, for user notification and response when a website that has not been previously visited, or that is not in a whitelisted domain, tries to use the plugin. The dialog box is displayed in front of the browser. On some OS/browser combinations, the user may not be able to interact with the browser or interact with the webpage while the dialog box is open.

This feature is invoked when the plugin is initialized. It specifies the domain that it is requesting permission and provides the user with the option to Deny, Allow, or Always Allow access to a desktop phone, camera or, microphone.

Always Allow selections are shared across all browsers on both Macintosh and Windows systems.

Access Control Dialog box

Delayed User Authorization

In addition to providing the Access Control Dialog, the API provides methods to control when the dialog is displayed.

To enable the Delayed User Authorization functionality, an application must specify a callback function as the delayedUserAuth property in the settings object that is passed to the init method.

If the delayedUserAuth setting is false or not present, or if the plug-in has been whitelisted for the site, behavior in regards to the authorization dialog is the same as in release 3.0.0.

If the delayedUserAuth callback is present, it will be called if the plug-in has not yet been authorized for the site.

If the site was not previously authorized by the user or administrative whitelist, and the application provides a delayedUserAuth callback, the application must use the showUserAuthorization API and successfully authorize the site to the user before using the CWIC API.

The showUserAuthorization API displays the user authorization dialog. If the user chooses allow or allow always, the settings.ready callback will be called as normal. If the user chooses deny, the denied callback provided to the showUserAuthorization API will be called, and the application should not use the CWIC API or plug-in. Once the user has denied authorization, most CWIC API calls will result in the error NotUserAuthorized.

Example:

To delay showing the access control dialog, use following function:

CopydelayedUserAuth parameter to cwic('init'):

    function delayedUserAuthCallback() {
    // Indicate that the plug-in is not authorized.
    $('#auth-status').text('Plug-in not authorized');
    }

Then after the delayedUserAuth callback has been made, call cwic('showUserAuthorization') with the denied callback as one of its parameters. This can be done in response to a button click, a timer, or some other user interaction.

For example:

Copy$('#auth-button').click(function() {
    $('#container').cwic('showUserAuthorization', {
    denied: function() {
        alert('Plug-in authorization denied by user.');
    }
    });
    });

Once cwic('init') is called, you may call cwic('about') at any point to determine version information of the plug-in. No other CWIC API calls should be made until either the 'ready' or 'delayedUserAuth' callback has been called. The callback is the application's indication that the asynchronous plug-in load is complete.

Domain whitelist support

An administrator is able to add domains to the whitelist. The plugin install process does not modify the existing whitelist entries.

Mac OSX.x

On OSX.x, an administrator adds the whitelisted domains to the plugin preference list: com.cisco.CiscoWebCommunicator.plist.

For example, to whitelist jabberweb.cisco.com, create the Key AlwaysAllow_jabberweb.cisco.com and set its Boolean value to Yes.

For user-specific preferences, add com.cisco.CiscoWebCommunicator.plist to the *~/Library/Preferences/ *folder. Overwriting this file may remove existing entries.

For system-wide preferences, add com.cisco.CiscoWebCommunicator.plist in the root HD/Library/Preferences/ folder.

Windows

In order to whitelist a domain, create a DWORD registry value under the following keys with the specified parameter values.

User whitelist

Key: HKEY_CURRENT_USER\SOFTWARE\Cisco Systems, Inc.\Web Communicator\AlwaysAllow

Domain to whitelist: jabberweb.cisco.com

Boolean value: 1

Administrator whitelist

Key: HKEY_CURRENT_USER\SOFTWARE\Policies\Cisco Systems, Inc.\Web Communicator\AlwaysAllow

Domain to whitelist: jabberweb.cisco.com

Boolean value: 1

Note: The Windows® plugin merges the administrator and user allowed domains by reading these two registry keys.

As of 3.0.1:

Under the admin whitelist, administrators can use either key to push whitelisted domains out to users.

Administrator whitelist:

HKEY_CURRENT_USER\SOFTWARE\Policies\Cisco Systems, Inc.\Web Communicator\AlwaysAllow

HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Cisco Systems, Inc.\Web Communicator\AlwaysAllow

Note: Whitelisting is intended for managed environments where registry changes can be pushed out through some standard process.

Language support

The Access Control Dialog box supports localization of the user notification message.

Languages

• Arabic (Saudi Arabia)
• Bulgarian
• Catalan (Catalan/Spain)
• Chinese (China)
• Chinese (Taiwan)
• Croatian
• Czech (Czech Republic)
• Danish (Denmark)
• Dutch (Netherlands)
• English (United States)
• Finnish (Finland)
• French (France)
• German (Germany)
• Greek (Greece)
• Hebrew (Israel)
• Hungarian
• Italian (Italy)
• Japanese (Japan)
• Korean (Korea Republic)
• Norwegian Bokmal (Norway)
• Polish (Poland)
• Portuguese (Brazil)
• Portuguese (Portugal)
• Romanian
• Russian (Russia)
• Serbian (Republic of Montenegro)
• Slovak
• Slovenian
• Spanish (Spain)
• Swedish (Sweden)
• Turkish (Turkey)
• Thai (Thailand)