DRF + React is Session auth usable? - django

I am trying to use Session auth in Django with React. All my GET REST calls are being reject with status 403. I probably have to send sessionidin headers, but sessionid cookie is HTTP only, so my JS code gets a null value when reading it. If I set the cookie to not be HTTP-only anymore, I can read it and send it in headers, but still seing the same problem.
Note: the view which includes the React app has a path /app, the REST api path is /api. Could this be the problem?

This is actually related to the fetch library I am using for making API calls. In order to send the sessionid automatically, credentials: include must be added in options.

Related

OIDC js library reponse cookies are not stored and not attaching for subsequent requests

I am using authcodeflow with PKCE.
Using OIDC js library in the frontend, making calls to adfs getting an auth code and then calling my backend api. The backend api which calls adfs server get the access token and the backend api returns the token as a cookie to the frontend. I can see the cookie in response headers. but That cookie is not stored in browser and not getting added for subsequent requests. I have tried with samesite with all modes -> Lax, None,Strict and not setting.
Is this an issue with OIDC js library or is it blocking the cookies to store in browser?
Update:
Below are the observation with my analysis
Since the OIdc-client-js does not have an option to set flag "withCredentials" to true for the requests. There are no cookies send in the request and response cookies are ignored for the cross origin requests.This changes are marked as enhancement and still not completed in thier github repo.
https://github.com/IdentityModel/oidc-client-js/issues/1062
Is there any way to achieve with this library? or any other libraries for OIDC js
https://developer.mozilla.org/en-US/docs/Web/API/XMLHttpRequest/withCredentials
So you are issuing a cookie from an API domain that is a sibling of the WEB domain:
web.mycompany.com
api.mycompany.com
Cookie domain = .mycompany.com
POSSIBLE CAUSES FOR COOKIE BEING DROPPED
Maybe it is the withCredentials flag or maybe due to a lack of user gesture, since the user has not done anything explicit to navigate to api.mycompany.com, such as a browser navigation or clicking a link?
FORCING WITHCREDENTIALS
You can override the prototype like this in order to add the withCredentials property. This is a little hacky but you could limit usage based on the URL and it should let you know whether setting withCredentials resolves your problem:
let open = XMLHttpRequest.prototype.open;
XMLHttpRequest.prototype.open = function(method, url) {
open.apply(this, arguments);
this.withCredentials = true;
}
PROXYING VIA WEB DOMAIN WILL HAVE FEWER COOKIE ISSUES
In my blog post I do something similar to proxy messages containing a refresh token. I use the web's exact domain though, rather than using an API subdomain. This will never be impacted by browser restrictions.

Http post request to a Django webservice (need login info) using Postman

I want to send a http request to a webservice ,which I implemented earlier, that need the user to be login. Now, I implemented a form page that do this for me and I need to change it for every different request.
As far as I know, Django need "csrftoken" and "sessionid" to allow requests. Unfortunately, I can not figure out how to add this two field to Postman client and interact with my Django services.
Postman receives cookies from chrome and you can retrieve them using the Postman interception plugin.
See here
Now after installing the plugin :
Create a new environment so environment variables can be stored
Create a method with a test to store the XSRF cookie value in an environment variable, in the test tab post this code
var token = postman.getResponseCookie("XSRF");
postman.setEnvironmentVariable("xsrf-token", token .value);
Now you will have an environment variable with xsrf-token in it.
Save your method
Create the new post and add XSRF-Token-Header Key in the header.
Access the token value with {{xsrf-token}}
Now before running your new request make sure you run the method, so that it can store the environment variable, and then when you run the actual request it will append its value in the header.
You can also refer this post.
Just in case : For ajax requests you can refer to the django docs

Authentication with Flask/Django and a javascript front end

I'm struggling to understand how flask_login or django knows when a user logs in that they retain access?
If I were to use ReactJs or Angular with flask-restful or django/tastypie, what is being added to the header/body of future json requests to ensure that my user stays logged in?
This is done via sessions, which is based on cookies. From the Flask documentation:
In addition to the request object there is also a second object called session which allows you to store information specific to a user from one request to the next. This is implemented on top of cookies for you and signs the cookies cryptographically.
and the Django docs:
Django provides full support for anonymous sessions. The session framework lets you store and retrieve arbitrary data on a per-site-visitor basis. It stores data on the server side and abstracts the sending and receiving of cookies. Cookies contain a session ID – not the data itself (unless you’re using the cookie based backend).
So, the requests to the server automatically include a cookie that indicates some ID that the server then uses to figure out what the session data should be for the given user. In general, when Ajax requests are made from client-side applications to the server, this cookie is included and so ensures that the user is considered to be logged in for those requests.
In some cases, you can also (optionally) manually add a special header to HTTP requests to indicate which user is logged in.
See also Securing RESTapi in flask for some more information.
If you use REST service then you should take a look at oAuth. In other words it uses token which you attach to every request from client to server and the last can determine which user sent this request by this token.
On the other hand, you can use cookie or session to determine a user status. And in this case you don't need to add any headers to your request.
Also I recommend you this package for Django - Django Rest Framework (there you can read more about token and auth via REST) and this extension for Flask.

IODocs - Passing cookie between API calls

I have a REST website built with flask, and use its session cookie features to keep a very basic 'login' (I don't require security).
I'm trying to implement iodocs documentation. The "/login" works fine, and I also see the response with the cookie being sent, but I can't figure out how to tell iodocs to keep that cookie for the next API calls.
Any help (that wouldn't require my site to change to OAuth) would be very appritiated.

Send Django CSRF Cookie with YUI Uploader Request

I am trying to use the YUI uploader to upload files to Django view.
However, I am getting a 403 error in CsrfViewMiddleware. I have determined that the problem is due to the flash uploader (that the YUI uploader uses) not sending the CSRF cookie in the file upload request.
The YUI uploader's uploadAll() function allows additional data to be sent with the upload request in object form. Since the CSRF cookie can be easily retrieved, I am trying to add the cookie to the request via the uploadAll() function, but I am not entirely sure as to what format to send it in so that CsrfViewMiddleware finds the cookie where it expects it. This does not work:
var cookie = YAHOO.util.Cookie.get('csrftoken');
uploader.uploadAll(url, 'POST', { csrfmiddlewaretoken: cookie });
Any insight would be greatly appreciated!
Unfortunately, because of Flash player limitations, the YUI Uploader can't insert the cookie into the header of the request, which is where the backend expects it to be. The only thing you can do, which is what that additional argument up there does, is to add POST variables to the request. However, that means that you need additional server logic to extract them as POST variables and them compare them to the cookie record -- it won't work by default.
If you are unable to modify the server-side code, you won't be able to authenticate the requests sent from the Uploader :(.