You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We use two different forms of user authentication:
When a user logs in on the platform site, we store a session token as a cookie in their browser, and this is used to authenticate the user for access control;
For API requests, the user makes a request to the api/v1/account/login endpoint to get an authentication token. This token is then used for authentication in subsequent API requests, by including an HTTP header of the form Authorization: Token <token> where <token> is the authentication token returned from the login endpoint.
The only problem with this setup comes when it becomes necessary to make API requests from the platform Javascript code using Ajax. There needs to be some mechanism to "bridge" the session-based authentication to the token-based authentication used by the API endpoints. At the moment, I believe (based on some admittedly not very good experiments -- see below) that, even if the session cookie is being passed as part of Ajax requests (and I'm not even sure about that), it's not being interpreted as proof of authentication by the djoser API authentication backend.
We need to do something about this before we get into making Ajax API requests from the front-end Javascript (which is going to happen soon).
Experiment
Add the following to the bottom of cadasta/templates/core/base.html:
Log in and add some resources to the "London 1" project in the "Cadasta" organization.
Observe that the console log shows an empty list of resources for the Ajax requests whenever a page load happens, even as you add resources to the project.
What's happening here is that you're getting the resource list than an unauthenticated user would see.
The text was updated successfully, but these errors were encountered:
It seems that this can be fixed by adding rest_framework.authentication.SessionAuthentication to the DEFAULT_AUTHENTICATION_CLASSES in the REST_FRAMEWORK section of the Django settings. If you do this, Ajax calls from the platform Javascript work fine (you don't even seem to need to set the withCredentials flag in the $.ajax call).
We use two different forms of user authentication:
api/v1/account/login
endpoint to get an authentication token. This token is then used for authentication in subsequent API requests, by including an HTTP header of the formAuthorization: Token <token>
where<token>
is the authentication token returned from the login endpoint.The only problem with this setup comes when it becomes necessary to make API requests from the platform Javascript code using Ajax. There needs to be some mechanism to "bridge" the session-based authentication to the token-based authentication used by the API endpoints. At the moment, I believe (based on some admittedly not very good experiments -- see below) that, even if the session cookie is being passed as part of Ajax requests (and I'm not even sure about that), it's not being interpreted as proof of authentication by the
djoser
API authentication backend.We need to do something about this before we get into making Ajax API requests from the front-end Javascript (which is going to happen soon).
Experiment
Add the following to the bottom of
cadasta/templates/core/base.html
:Log in and add some resources to the "London 1" project in the "Cadasta" organization.
Observe that the console log shows an empty list of resources for the Ajax requests whenever a page load happens, even as you add resources to the project.
What's happening here is that you're getting the resource list than an unauthenticated user would see.
The text was updated successfully, but these errors were encountered: