Just a few thoughts, having just jumped through some CORS hoops recently on an unrelated project. If you decide to go the RESTful route (though I agree it's probably not a best practice), I think you'd want to have something analogous to a service whitelist for configuring this on the server-side. CORS requests are typically preceded by an OPTIONS request that would have a header like this:
Origin: https://casifiedapp.domain.com You'd have to check the whitelist to see if 1) that domain is on the whitelist, and 2) that domain is allowed to issue service-oriented authentication. In that case, the server would return this header (and maybe a few other Access-Control- headers controlling content types and request methods). Access-Control-Allow-Origin: https://casifiedapp.domain.com If it fails the test and you don't return that header, the REST call will fail. I think that behavior would be appropriate here. The service whitelist seems like it would be a good place to build this (just add a checkbox for a service indicating whether to allow CORS requests or not), but I don't think it's that simple. The tricky part (I'm pretty sure, anyway) is that the Origin header passed from the browser is always going to be at the domain level, where I believe the service whitelist is more granular than that. So if your app has it's own domain name, you'd be all set, but if you have multiple apps under a single domain, I don't know how you'd restrict CORS to specific apps under that domain. You'd have to whitelist the entire domain for CORS... so you might need 2 separate UI's to manage this. Though it would seem to make sense that the CORS whitelist should only contain a subset of the domain names in your service whitelist and never anything else. If you decide to go this route, I'd recommend using Firefox and not Chrome for testing. Chrome seems to literally kill the OPTIONS request when the CORS security checks fail, so you don't get very good diagnostic information as to what went wrong. It looks like the request was just disconnected and you can't view the response headers. Firefox will show you the HTTP response headers on the OPTIONS request. -Scott On Mon, Apr 15, 2013 at 11:53 AM, Venkat <[email protected]>wrote: > We have our own UI application that has the login screen. UI won't flow > well if for login alone we have to take the user to CAS login page. > -- > You are currently subscribed to [email protected] as: > [email protected] > To unsubscribe, change settings or access archives, see > http://www.ja-sig.org/wiki/display/JSG/cas-user > -- You are currently subscribed to [email protected] as: [email protected] To unsubscribe, change settings or access archives, see http://www.ja-sig.org/wiki/display/JSG/cas-user
