Cross Domain - Allow Multiple Domains

Matt_Aze

Am trying to configure a cross domain Content Server and ajax request for data, and single sign on.

I can setup so works for a Single cross domain server, but not mutlple, as Internet Explorer will allow following settings but Google Chrome will not unless full domain name.

So what works.

in Content Server - settings - Configure Security Parameters -
I have my domain address where ajax data reuest (example: https://servername.domain.site.com) coming from added to 
Trusted Referring Websites and Trusted Cross Domains

In IIS (Internet Information Services 7) - have a website in default, set up for Single Sign On. 

so content server at http://contentserver.domain.site.com/otcssso/llisapi.dll

Following settings on content server IIS, allow for ajax call to work:
in IIS HTTPS Header Response, added 
Access-Control-Allow-Credentials = true
Access-Control-Allow-Origin = http://servername.domain.site.com

and website on http://servername.domain.site.com makes call to  http://contentserver.domain.site.com/otcssso/llisapi.dll?....query parameters...

This works for Internet Explorer (10) and Google Chrome.
But what if I want multple cross domains to be allowed.

so first change is with Access-Control-Allow-Origin = https://*.domain.site.com
This works - but only for IE, because IE i am guessing cares less about security then Chrome.

Chrome throws that access-control-allow-Origin does not match origin is "https://servername.domain.site.com" and allowed is "https://*.domain.site.com" 

So someone must have set this up before.
Is there a setting in IE that needs to send the referal to Content Server component. Content Server allows adding in multple Cross Domain locations.
IIS does not allow multple settings of Access-Control-Allow-Origin

A result on the internet does point to chaning the OptionsVerbHandler, but could not find reference on knowlage center.

Thanks for any assitance that can be provided.

Ferdinand Prantl

Trusted Referring Websites do not allow the CORS AJAX.  Your approach with the Access-Control headers is correct, but if you want to use cookie authentication, it will not work with static origin value.  Dynamic origin is standized too:

Access-Control-Allow-Origin = *

But you cannot combine it with "Access-Control-Allow-Credentials = true".  Cookie transfer requires a concrete origin value, which you cannot setup in the static IIS configuration - it has to match the request origin.

You could set the value in your own IIS module (ISAPI Filter) or, probably easier, from your OScript request handler.  Have a look at RESTAPI:RestApiUtils.GetCrossOriginHeaders.  You can use it and add the result string to .fExtraHeaders in your request handler.  This is how the CS REST API enables CORS; see RESTAPI:RestAPIRequestHandler._AddCrossOriginHeaders.  If you write a new request handler, consider making it RESTful - create a CS REST API resource.  CS REST API handlers have the CORS built in.

Also, consider dropping the (automatic) cookie authentication.  It is an open door to XSRF.  CS REST API allows using the value of LLCookie (or other token accepted by the CS login callbacks) but your application portal is supposed to negotiate it (you usually have SSO); not relying on a side-login to the CS home page.  (If your HTML page runs on the CS it is easier, because your authenticating portal ois the CS itself, where you have the LLCookie value.)

Different browsers allow different options to turn the security off and make the XMLHttpRequest succeed although the server didn't aalow the CORS request to succeed (IE has Miscellaneous -> Access data sources across domain, Chrome has --disable-web-security, FF has nothing), but they are only workarounds for prototyping and early development.