REST OERealm form security login using CORS

Posted by fredhamelin on 01-Dec-2014 15:41

Hi, I have been trying to use CORS with my REST service and it seems to work once I'm authenticated. But if I try to authenticate via a cross-domain ajax call, the preflight OPTIONS request returns a 403 Forbidden error. 

Here is my current config for the OECORSFilter :

<b:bean id="OECORSFilter"
class="com.progress.rest.security.OECORSFilter" >
<b:property name="allowAll" value="false" />
<b:property name="allowDomains" value="*" />
<b:property name="allowMethods" value="GET,POST,PUT,DELETE,OPTIONS" />
<b:property name="messageHeaders" value="x-requested-with" />
<b:property name="supportCredentials" value="true" />
</b:bean>

Is there a way to authenticate from another domain or I absolutely have to use the login form in static/auth/login.html  ?

Posted by Michael Jacobs on 02-Dec-2014 05:13

From your configuration I see one thing that is unusual and one thing that probably causes an error.

I notice you have "allowAll" set to 'false', which requires every http client to negotiate a CORS request.   Is this what you want or to just require the java-script clients to negotiate CORS access?   Just curious to why you set 'false'.

The highest probability for a failure is the "messageHeaders" property.   When you enter a value it replaces the default list of headers with the exact value you specify.  So the only header that will be negotiated would be "x-requested-with" and the client is probably sending others that are no longer allowed.

You may want to try using the property value "+x-requested-with".  The plus sign ("+") will append the remaining string value (x-requeted-with) to the end of the default header values.

I cannot find the documentation for configuring REST security, so I'm added  what the default list of request and response headers are:

request headers:  "Accept,Accept-Language,Content-Language,Content-Type,X-CLIENT-CONTEXT-ID,Origin,Access-Control-Request-Headers,Access-Control-Request-Method,Pragma,Cache-control,Authorization"

response headers: "Cache-Control,Content-Language,Content-Type,Expires,Last-Modified,Pragma,X-CLIENT-CONTEXT-ID"

To debug the details of why CORS failed, you edit the web application's /WEB-INF/classes/log4j.properties and change the line containing "com.progress.rest.security" to "DEBUG".   (This will log LOTS of information including the CORS filter - so using grep or some other text search tool will be your friend )

All Replies

Posted by Michael Jacobs on 02-Dec-2014 05:13

From your configuration I see one thing that is unusual and one thing that probably causes an error.

I notice you have "allowAll" set to 'false', which requires every http client to negotiate a CORS request.   Is this what you want or to just require the java-script clients to negotiate CORS access?   Just curious to why you set 'false'.

The highest probability for a failure is the "messageHeaders" property.   When you enter a value it replaces the default list of headers with the exact value you specify.  So the only header that will be negotiated would be "x-requested-with" and the client is probably sending others that are no longer allowed.

You may want to try using the property value "+x-requested-with".  The plus sign ("+") will append the remaining string value (x-requeted-with) to the end of the default header values.

I cannot find the documentation for configuring REST security, so I'm added  what the default list of request and response headers are:

request headers:  "Accept,Accept-Language,Content-Language,Content-Type,X-CLIENT-CONTEXT-ID,Origin,Access-Control-Request-Headers,Access-Control-Request-Method,Pragma,Cache-control,Authorization"

response headers: "Cache-Control,Content-Language,Content-Type,Expires,Last-Modified,Pragma,X-CLIENT-CONTEXT-ID"

To debug the details of why CORS failed, you edit the web application's /WEB-INF/classes/log4j.properties and change the line containing "com.progress.rest.security" to "DEBUG".   (This will log LOTS of information including the CORS filter - so using grep or some other text search tool will be your friend )

Posted by fredhamelin on 02-Dec-2014 07:59

The plus sign seems to solve the problem. Thanks a lot !

And for the "allowAll" set to false, there was no particular reason for it. I had just tried setting it to false while searching for a solution to my problem.

Posted by Michael Jacobs on 02-Dec-2014 08:28

I'm happy to see that the information was useful and you have gotten past that issue.  

This thread is closed