# SOLVED Request denied due to possible CSRF attack **URL:** \ **Category:** OSLC implementations\ **Created:** [September 27, 2023, 5:50pm UTC](https://forum.open-services.net/t/solved-request-denied-due-to-possible-csrf-attack/764 "2023-09-27T17:50:24Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![betasharko](https://forum.open-services.net/user_avatar/forum.open-services.net/betasharko/32/267_2.png) [@betasharko](https://forum.open-services.net/u/betasharko)\ **Post date:** [September 27, 2023, 5:50pm UTC](https://forum.open-services.net/t/solved-request-denied-due-to-possible-csrf-attack/764/1 "2023-09-27T17:50:24Z")
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. ![Screenshot from 2023-09-27 19-45-06](https://forum.open-services.net/uploads/default/original/1X/cc8d41e5e46ba4dbd5ac63ff6288be6f858ca19b.png) But the problem stays! Could please somebody say me what I’m missing? Thank you very much in advance! ---
**Author:** ![jad](https://forum.open-services.net/user_avatar/forum.open-services.net/jad/32/42_2.png) [@jad](https://forum.open-services.net/u/jad)\ **Post date:** [September 28, 2023, 7:14am UTC](https://forum.open-services.net/t/solved-request-denied-due-to-possible-csrf-attack/764/2 "2023-09-28T07:14:53Z")
Hi Dmitry 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? > Let’s see what you get there? ---
**Author:** ![betasharko](https://forum.open-services.net/user_avatar/forum.open-services.net/betasharko/32/267_2.png) [@betasharko](https://forum.open-services.net/u/betasharko)\ **Post date:** [September 28, 2023, 6:24pm UTC](https://forum.open-services.net/t/solved-request-denied-due-to-possible-csrf-attack/764/3 "2023-09-28T18:24:10Z")
Hi Jad, 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. ![Screenshot from 2023-09-28 19-58-13](https://forum.open-services.net/uploads/default/original/1X/8e7e006db9b1ec95c6476fe089b0660014c23d90.png) 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! ---
**Author:** ![jad](https://forum.open-services.net/user_avatar/forum.open-services.net/jad/32/42_2.png) [@jad](https://forum.open-services.net/u/jad)\ **Post date:** [September 30, 2023, 1:18pm UTC](https://forum.open-services.net/t/solved-request-denied-due-to-possible-csrf-attack/764/4 "2023-09-30T13:18:09Z")
Hi 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). regards Jad ---
**Author:** ![andrew](https://forum.open-services.net/user_avatar/forum.open-services.net/andrew/32/28_2.png) [@andrew](https://forum.open-services.net/u/andrew)\ **Post date:** [October 7, 2023, 5:42pm UTC](https://forum.open-services.net/t/solved-request-denied-due-to-possible-csrf-attack/764/5 "2023-10-07T17:42:53Z")
Hi, I can’t help you with the exact issue but here are some comments: 1. `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. 2. `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. 3. I usually saw CSRF checks only done via hidden form fields. This is the first time I see it done via a special header. /A ---
**Author:** ![betasharko](https://forum.open-services.net/user_avatar/forum.open-services.net/betasharko/32/267_2.png) [@betasharko](https://forum.open-services.net/u/betasharko)\ **Post date:** [October 9, 2023, 6:12pm UTC](https://forum.open-services.net/t/solved-request-denied-due-to-possible-csrf-attack/764/6 "2023-10-09T18:12:00Z")
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: ![Screenshot from 2023-10-09 19-54-28](https://forum.open-services.net/uploads/default/original/1X/36170d23ea1086f76536104929cca3a49d92c4c5.png) 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. ---
**Author:** ![betasharko](https://forum.open-services.net/user_avatar/forum.open-services.net/betasharko/32/267_2.png) [@betasharko](https://forum.open-services.net/u/betasharko)\ **Post date:** [October 10, 2023, 10:59am UTC](https://forum.open-services.net/t/solved-request-denied-due-to-possible-csrf-attack/764/7 "2023-10-10T10:59:36Z")
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. ---
**Author:** ![jad](https://forum.open-services.net/user_avatar/forum.open-services.net/jad/32/42_2.png) [@jad](https://forum.open-services.net/u/jad)\ **Post date:** [October 10, 2023, 8:50pm UTC](https://forum.open-services.net/t/solved-request-denied-due-to-possible-csrf-attack/764/8 "2023-10-10T20:50:41Z")
Yes, among many things, you don’t want to mix https & http between the applications.