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.
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).
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.