Hello guys!
Could I please ask you to help me with OSLC adapter implementation? It seems that the issue isn’t difficult but I can not solve it, honestly.
I have an implementation of OSLC adapter v5.1.1.Final. The most of the code was generated with Eclipse Lyo Designer. It includes Authentication element and Oath Web app is embedded into the deployed WAR archive.
The solution works fine if baseUri contains localhost. But I need to use it in another domain in a closed customer’s network. When I try to change localhost to another name (registered in hosts file in my local development environment), I get “Request denied due to possible CSRF attack” message when it tries to request access token with POST request to “…/oauth/login”.
Trying to solve the problem, I found a solution from Andrew (I believe):
It was a bit redeveloped but nevertheless it adds the respective headers in a filter and sends the data back into filters chain.
I am suspecting the problem is not related to CORS.
The problem sounds very familiar, but don’t have a single explanation, or single reason for the problem.
I suggest you trace into the the operation that handles the request “…/oauth/login”, and dig into exact reason of the failure first?
Based on your tip, I have added the sources of Oauth web app directly into my code and found the reason of the problem. Apparently, “X-CSRF-Prevent” header with JSESSIONID value must be included into HTTP request.
Next, the problem disappeared. I will think how it can be modified from Jazz side, or at least I know how to excluded this check. Or may be a bit modify it under our needs.
Thank you very much!
Not sure exactly how you worked around the problem. But indeed as suspected, it’s that piece of code that is raising the exception.
The code is there for a good reason. You will find this problem as soon as your consumer application (Jazz) is running under a different domain than that of the server. That’s why you don’t see the problem if both are running under the same domain (like localhost).
I can’t help you with the exact issue but here are some comments:
Access-Control-Allow-Credentials is always set to false if the A-C-A-Origin is set to *. For the header value true to have effect, the A-C-A-Origin must be the real domain making the request.
A-C-A-Headers does not list the X-CSRF-Prevent header. Even if your JS request will include the header, I don’t think the browser will pass it along.
I usually saw CSRF checks only done via hidden form fields. This is the first time I see it done via a special header.
Hi Andrew,
Thank you for sharing your remarks! I was playing with various variants of the headers mentioned by you but it didn’t help. Nevertheless, some idea came to me during that research. As for my tries in Postman above, I believe that the problem was that I was using some random token and unclear session that’s why it didn’t work.
But the idea came when I tried to research the data from Jazz directly. There’s a curious screenshot provided next:
As if the session ID can not be correctly set because of the block shown above.
May be the main problem is that I need use proper domain names with SSL protocol, and may be even correctly provided certificates. May be this is another wrong way but I remember that somebody was already speaking me about that. Honestly, I missed it. Anyway, I think that it makes the sense to analyze it next days.
Yes, a lot of problems gone away after testing the solution locally with HTTPS and a self-signed certificate! It seems that now it works. But I will test it in detail of course.
