The server I'm using sends the session id with a http-only cookie.
To make this working on WP8, I already enabled cookies in the internet explorer settings of the device. This works well for all my AJAX-requests.
But now i have to download a file from the server, therefore I'm using the file-transfer plugin, but i always get HTTP Status 401 - Http Request not attached to a session
Is there any way to fix this issue, so that the cookie header containing the JSESSIONID is sent with the download request?
Related
Scenario 1: Working fine
The application receives all the requests through Azure App Gateway. The application sets some value for the session cookie "JSESSIONID" in the response of first "/login" endpoint (set by Spring security). This same JSESSIONID cookie value is then used in the request header of "/login?code=<some_code>&state=<some_state>" api, which is the callback url from the Authorisation server. So, in this case, the auth server is able to identify the client based on same session cookie value. We can infer that Azure app Gateway sends the cookie forward. There is no specific settings done in App Gateway.
Scenario 2: Issue
Now the application receives the request through Azure App Gateway from Apigee. The callback url is also set to the apigee url. The application sets some value for the session cookie "JSESSIONID" in the response of first "/login" endpoint. But when the callback url "/login?code=<some_code>&state=<some_state>" is invoked after Auth server validation success, there is no "JSESSIONID" in the request header. So, possibly Apigee is stripping of this cookie.
The other cookies like "SameSite", "ADRUM_BTa" and "ADRUM_BT1" are passed in the request header of the callback url in both the scenarios.
Could someone please help here, if there is any settings change that needs to be done in Apigee so that it sends the cookie in the request header of callback url.
This was resolved by setting the session cookie path in the Application equal to the URI backend path of the Apigee configuration.
server.servlet.session.cookie.path=/backend/path/configured/in/apigee/proxy
As the session cookies are always set based on path. By default, without the above code, the session cookie path was set to the server context path of the application.
I'm doing this -
Load single page application - an apollo client is initialised with a websocket and http link. This happens when the user is logged out, let's say.
The user then logs in without a page reload. The graphql response now contains the session cookie.
Problem - whilst subsequent http requests include the session cookie the websocket connection does not.
How do people solve this problem?
I'm guessing either make all communication with the server via websockets, or, create a new apollo client upon successful sign in and use this for subscriptions.
This is for a chat app. I'm using http and websockets at the moment.
I am trying to build a web app using Django and DRF at the back-end and ReactJs at the front end and I want to keep them separate (i.e. avoid Server Side Rendering).For authentication purposes, I want to employ JWT and I am using djangorestframework-jwt for that. I have read it at several places that it is not secure to store JWTs in the local storage so I am trying to use HttpOnly cookies for that. One can achieve that by configuring the django server to send HttpOnly by overriding the following default settings of the drf-jwt package in the settings.py file of your project JWT_AUTH = { 'JWT_AUTH_COOKIE': '<cookie name>', } which is set to none by default. The server sends the httpOnly cookie as anticipated but there are a few issues I am facing:
1.Same Domain Restraint
I am aware that httpOnly cookies wont be attached to the request headers unless the request is being made to the server which is hosted on the some domain. In my case I am using localhost:8000 for django and localhost:3000 for my react project so the browser doesnt attach the cookie as the request is made to a different port. I tried running both app on port 3000 simultaneously, and the browser did attach the cookie in the header and I did get the a 302 response from the server. However, it opened door to all sorts of problems due domain clash. I reckon I can solve this problem using nginx reverse proxy or something like that but I am not sure about it. Do guide me how can I serve both apps on the same host during the development.
2. Token Refresh Problem
When I refer to the view setup to refresh the token, I run into a bad request error even when the browser does attach the cookie along the request header. This is the server response in the browser
{"token":["This field is required."]}
Thanks if for reading it all the way down here!
In order for things to be secure:
You need CORS (Quickstart: CORS_ALLOWED_HOSTS=["http://localhost:3000"], CORS_ALLOW_CREDENTIALS=True)
The short-lived token (session) cookie (5-15mins), should NOT have HTTP-ONLY setting
The refresh token cookie SHALL have HTTP-ONLY setting
Then your basic flow is:
On login Django creates session token and sends it
Your SPA reads the cookie and adds its value to the authorization header (Authorization: JWT ...token...)
Any request to Django should be made with that Authorization header
The refresh flow is:
Send a request to the refresh token endpoint following the documentation of the library you use
Django then reads the HTTP-ONLY cookie and verifies it
If valid, Django sends a new refresh token as HTTP-ONLY cookie along with a new short-lived token session cookie
Once the refresh token has expired, you log the user out.
An article here goes into detail using GraphQL, but the cookie part and handling of most of the frontend code you should be able to adapt to REST.
I am using Ember and Ember-simple-auth. This question is to clear my confusion related to cookies etc.
I have configured ember storage to Cookie.
My server is sending a cookie to be saved at client side. i.e
Set-Cookie: dejavu.session=WwwLQjdfOoNz_-bhyYpBLvzew7IUaJuu; Path=/; Expires=Mon, 28-May-2018 15:59:30 GMT
I have understanding that
browser automatically captures the cookie from set-cookie in header (mean it should be visible in dev tool)
browser automatically add this cookie in subsequent requests.
I don't need to do anything extra with Ember Simple Auth as server cookie is by default handled by browser.
Based on this understanding, in Chrome inspector I just see one cookie of ember-simple-auth and nothing else.
My questions are:
1- Should I see a separate cookie (the one sent from server) in dev tool along with Ember cookie (set by Ember simple Auth)? or my server cookie has to be embedded in Ember Cookie? I actually don't see server cookie on my dev tools so I am confused.
2- Is this right concept that ember cookie is storage for Ember but server cookie is the one that browser will capture and send in header in subsequent requests?
ok. I found the solution after spending alot of testing and exploration.
Answer to my both questions is:
There is a bug in chrome dev tools that doesn't show the cookie sent from server. We don't need to embed server cookie in ember cookie. Browser manages cookies itself. Only server has to send a cookie and then browser will manage it e.g discard it if it expires and then automatically add it to header of each subsequent requests to be sent via api. We can see the cookie as request is sent, in our dev tools 'Network' tab under request headers.
With session cookie and Ember-simple-auth we don't need to set authoriser in header (for adding cookie in header) as this will override the session cookie (that was set by browser).
So when using Ember-simple-auth and session authentication, correct flow is:
add addon
setup authenticator (follow github docs)
don't set authorizer (as told in docs)
While developing a phonegap application, I can see the SetCookie header in responses from XHR login requests to an API I am using. As expected, when I inspect subsequent requests, I see the cookie being sent. I can also see that it is an httpOnly cookie, so I can't store it using scripts.
However, in the Chrome dev tools "Resources" I have no trouble deleting the cookie if I want to.
Yet, when I am running the application on an external iOS or Android device, using the Safari or Chrome Web Inspectors for each respective device, I can't see the cookies in the "Resources" panel. I don't see the cookie headers in requests or responses, either, yet somehow my requests are fine.
Is this a security measure, or is there an bug in my app/API to do with cookies?