M
Michael Jacobs
Guest
We have newer documentation coming out for the OERealm functionality. That should help fill in some of the blank areas the first versions had. One of the issues was setting the expectations regarding what the 'sample' provided and did not provide. The sample provided direction - but not implementation or an example of what could truly be accomplished using the OERealm functionality. We did not do a good job at that. As more PSC products use the OERealm functionality, you should see a marked improvement. CORS... and there begins an entire discussion. Yes, the REST services include a built-in standards compliant CORS security module that you can customize per the production site's requirements. The default is mostly *open* but is not * open - open*, if you get my meaning. You adjust the CORS configuration in the appSecurity-*.xml files. The client JavaScript engines I've seen implement domain security to block cross-site scripting attacks by the code. However, cross-site access is necessary and we needed a controllable access method. The JASON-P, in my opinion, is a hack. The CORS spec is I think a better answer: In the CORS model the client sends a 'captain may I..." to the server, and the server's CORS module responds with a "Yes, but only to these things" or a "NO - go away" response. The javaScript engine then control's the code's access to resources based on the server's response. The REST's CORS module allows you to control which clients (IP addresses), which http methods, which request headers, and which response headers. It still comes down to a synchronization of the client code's requirements and the server being configured to meet those requirements. Better?
Continue reading...
Continue reading...