Browser Content Redirection: whitelisting websites

Browser Content Redirection is a technology built around a URL whitelisting mechanism. Two policies are exposed in Studio for that purpose:

i. Browser content redirection Access Control List (ACL) policy settings (a.k.a the ACL policy)

ii. Browser content redirection authentication sites (a.k.a the authentication sites policy)

While the description in edocs tries to cover the general cases, there are some websites using intrinsic redirection mechanisms that make the whitelisting process more difficult.

[Note: websites that rely on Integrated Windows Authentication, or that require a pop-up Windows Security message box are not handled correctly by BCR with CWA 1905 or older. This is because our overlay browser (HdxBrowser.exe or HdxBrowsercef.exe) cannot display that window, hence the user is stuck on a blank page. See CTX230052 (current limitations section)

CWA 1907 for Windows and higher fixes this problem].

As an example of BCR redirections, we will look into Microsoft Teams.

It is essential that the Developer Tools is used to understand the website’s behavior before configuring any policy.

The ‘Preserve Log’ check-box should be ticked, otherwise entries are cleared automatically.

User-added image

Microsoft Teams

A user typing will get an HTTP 307 response from the webserver, repointing the browser to

(Hence it is critical that the right syntax is used when whitelisting a website, like http or https, with or without www, etc – otherwise redirection might fail).

From that URL, the resource is contacted by the browser, which eventually ends up being redirected to:

Once the browser loads this page, it ‘rests’ and waits for user input. These redirections occured very fast, and the HdxVideo.js javascript that the Browser Content Redirection Chrome Extension needs to inject is not done in time.

In this case, the url* needs to be whitelisted in the ACL policy in Studio.

Since Admins might not want to redirect the entire domain, better granularity can be achieved by leveraging a common parameter in OAuth 2.0 (redirect_uri, where the App name is embedded in the URL).

So whitelisting the following URL in the BCR ACL policy in Studio will achieve the objective, thanks to wildcards:*teams*

The Chrome Extension will now be able to inject HdxVideo.js, and the first redirection happens. The user will end up being redirected to an Office 365 Authentication website that is linked to Teams (see screenshot above), but this time the website will be running locally on the endpoint’s overlay browser that is part of Workspace app (HdxBrowserCef.exe).

Important: Please note that any IdP/SSO websites your organization deployed to authenticate users in O365 will also need to be added to the Authentication Sites policy (e.g.

Please also note that Teams will require to add* to the Authentication Sites.

After a successful authentication, the overlay browser HdxBrowserCef.exe is pointed back to

This URL (*) should now be whitelisted also in the ‘Authentication Sites’ policy in Studio.

Note: This might be somehow counter intuitive as the Authentication site is, not – yet the problem in Teams is that the Chrome Extension is not loaded fast enough by the Browser and therefore injection fails on

Browser Content Redirection treats websites whitelisted under the Authentication sites policy as child websites that must remain redirected if the parent website was in the ACL whitelist policy. In the Teams case then, is the child website of the parent

Note: Peer-to-Peer Video conferencing is currently not available with Teams and Chrome, so it will not work with BCR either. Once Microsoft officially supports Chrome browser for peer to peer video, BCR will support it automatically.

Joining a conference call with video is supported in BCR.


First thing to notice is that navigating to redirects to

Whitelisting without the ‘www’ will result in failure. So whitelisting* is the solution (in the ACL policy).

Note the use of the wildcard ‘*’ – this allows you to whitelist any path for that URL.

After the webpage is redirected, the user can click ‘Join meeting in browser’, which points to:

User-added image

Note that this is a different FQDN. So if the user clicks on that link, he will fall back to server-side.

The solution is to whitelist*

You can either add this to the ACL policy or to the Authentication Sites policy (or both).

The difference is that if you add it only to the ACL policy, if the user clicks on the link it will trigger a re-processing of the URL by the VDA (look up of that URL in the ACL entries), resulting in a few extra redirection steps.

If you add it to the Authentication Sites policy, then since the parent website is* and that is already whitelisted in the ACL policy, a re-processing of the URL by the VDA is not required and the experience is smoother (see last paragraph under the Teams section).

Of course there could be a scenario where the user types directly as the first URL in Chrome’s navigation bar. Browser Content Redirection will only kick-in if that URL is on the ACL policy (that is because the Authentication Sites policy is only processed after an ACL match). So in order to prevent this exact scenario from failing, you can add the URL to the ACL and Authentication Sites policies (and hence the reference to ‘both’ in the paragraph above).

Microsoft Stream

Microsoft’s corporate video-sharing platform runs as an Office 365 service.

The URL* needs to be whitelisted in the ACL policy.

That is because whitelisting https://web.microsoftstream.comwill not work, since that page redirects to login.microsoftonline.comusing HTTP response status code 302 Found, and that page in turn redirects to

Once the browser lands on that website, clicking on Sign In will redirect to*microsoftstream*

where the user finally will insert his credentials.

Hence the site*microsoftstream* needs to be added to Authentication Sites.

(This is different from the behavior in Teams).

If you are using SSO solutions like OKTA, or ADFS, the URLs will need to be added under Authentication Sites also.

Finally, also add* to the Authentication Sites.

Google Meet and Google Hangouts

Add* to the ACL policy.

Add* to the ACL policy.

Important: Add* to the Authentication Sites policy.

Any other website used for SSO (e.g. Okta) must be added to the Authentication Sites policy (it could be more than one).

These websites require WebRTC support, hence you must use Citrix Workspace app 1809 for Windows or higher.

Currently, outgoing screensharing is not supported when using BCR.

Cisco Webex Teams

Add* to the ACL policy.

Add* to the Authentication Sites policy. This entry might vary depending on your Organization’s SSO configuration and IdP providers. Any website used for SSO must be added to the Authentication Sites policy (it could be more than one).

Cisco Webex Meetings

Currently not supported since this website uses Content Security Policy (CSP). See CTX230052.

Citrix and Cisco are collaborating on this and are aiming to have a solution ready.


  • No Related Posts

Leave a Reply