I am using Django v1.8 and django-rest-framework v3.2.2. I have a site with a public-facing API, which is also consumed by my own site (on the same domain) as the Ajax back-end to a JavaScript application, using GET only.
I want public users of this API to be asked for a key parameter in the URL, which I will issue manually. But I also want my JavaScript application to be able to use the API, in a way that means that other users can't just steal the key and use it.
I have set up my custom key authentication as described here, and it's working well.
However, I'm unclear on how the JavaScript application should use the API. Obviously I could just pass a dedicated key parameter in the URL, but then won't other users trivially be able to spot the key and use it?
I think I need SessionAuthentication, but how do I even start to make this work? I can't see any instructions in the DRF documentation about how I need to change my JavaScript calls to use it.
Also I don't understand how SessionAuthentication allows the Ajax app to authenticate without other users being able to see and copy the authentication.
Very grateful for any advice.
I think I need SessionAuthentication, but how do I even start to make this work? I can't see any instructions in the DRF documentation about how I need to change my JavaScript calls to use it.
SessionAuthentication is the Django's one. It uses session to authenticate a user. It's mostly transparent for ajax request as the browser will send the cookie automatically. However, if you're posting data, you need to make sure you send the CSRF token in both headers and post body.
Also I don't understand how SessionAuthentication allows the Ajax app to authenticate without other users being able to see and copy the authentication.
As said above, it uses cookies for that. They are part of the headers and thus usually not seen on the urls.
To make sure no-one else can steal user's session you need to run the site through https.
This isn't much different from regular websites.
Related
I have a django app that uses Google's allauth for signing up and logging in, but it first takes me to a google url and to sign in, i.e., my header and other parts of my site are not visible. Once I log in through my google account I'm redirected, so the logic works fine.
I'm just wondering if it's possible to have that process be done on my site.
For social auth I prefer to use Django Social Auth.
In regards to what OP is asking, I've never seen that before and as a user of a system I wouldn't want it like that. Who could grant me that OP wouldn't also be storing other relevant details of mine to perform that operation?
In fact, the idea of social auth is that one is passing the responsibility of authentication to Google or any other provider, hence going to their system to do that operation and then redirected back.
I'm using a third party API Key for my website. I have done some modification on that API and now I'm using it for my own site.
I want to secure that API data by adding a restriction on any user (Authenticated or Anonymous ).
I want to add a time limit on the data provided by the API. So, if anybody uses the same data after a certain period of time then it will show an error.
As well as I want some restrictions on users IP. So, a user can access my website a fixed number of time.
You might want to use the Django REST Framework JWT Authentication.
I implemented https://github.com/davesque/django-rest-framework-simplejwt
It works - the installation is rather easy - read the docs :)
if you are using DRF use the authentication class settings. If you are using normal Django views you can wrap the view with a login_required decorator
What is the right way to proceed the logout action of the User when using JWT, Rails API and a JS front-end framework, for example Ember JS ? What I'm actually doing is:
use Rails 5.2 as API
use Ember JS 3.3 as front-end
use Ember Simple Auth as OAuth add-on
example app, its master branch, works as needed
example app, its without login branch fails to logout the User
check the presence and pass in a token in every request between Rails API and Ember JS apps.
The questions I have are:
Should I keep a token value in the backend model (User, for example) ?
I need it to make another request in the background on the backend side.
Should I set the token value to nil when the User logs out in the backend ?
What am I doing wrong with ESA as for logout action ?
Actually the token value is kept in a cookie on the client side (see https://github.com/simplabs/ember-simple-auth for more details). I followed their guides and the dummy app they provide.
I also had a discussion on Ember JS Forum and tried to follow some tips and advises, still no success.
Thank you.
This answer applies to Ember 1.13 through at least 3.x.
Authentication comes in so many flavors that I think the right way to do it is whatever is an easy-to-understand fit with the back end.
Since your JWT is in a cookie, let's think of that cookie as the source of truth. Rather than doing something complicated to parse the cookie in a model hook, you could define a Service that has functions to grab the cookie, parse it, and either save the results to values on the service or return the values you need.
This gets you a few benefits. You can get the values from anywhere in your app, including adapters, and all the logic for auth lives in once place. On the other hand, you would have to handle async behavior yourself (i.e. if a route depends on having login info, you will have to manage the order of operations between authentication and route transitions).
Ember Simple Auth is quite popular because of this issue. Although there aren't out of the box features for JWTs in cookies, if you have an app with different states based on logged-in behavior, it might be a good investment to learn it.
The user model is kind of a middle ground between a hand-rolled service and Ember Simple Auth, since you can get the user model and rely on it throughout your app, plus get a little help with async. Just be careful not to scatter your auth code across your whole app.
Lastly, to trigger logout, I would create a function that destroys the cookie by setting the max age/expiration like this. If you are handling auth on a service, this means you could use Router Service and then transitionTo a login page. If you are using Ember Simple Auth, that functionality can go in the invalidate hook of your custom authenticator. Example:
invalidate() {
this._super()
document.cookie = "some_token_name=; expires=Thu, 18 Dec 2013 12:00:00 UTC; path=/"
return Promise.resolve();
}
Lastly, for passing the token to authenticate requests, if you are using Ember Data, this can be done easily in the adapter's headers method.
I’m making a simple Django app that takes data from a user submitted form, creates an image based on the data and displays the image to the user. The problem is that the form needs to be on an existing Wordpress site. The app will only perform this one task, and the image will be discarded, so there will be no user authentication, sessions, or anything like that. Is it safe to use #csrf_exempt to make this work?
Some of the answers to Do CSRF attacks apply to API's? suggest that a csrf token is not necessary if there is no user auth. However, some of the answers also suggest that there should be some other form of authentication in place instead.
And the answer to Django - CSRF verification failed - send data from form on static website to my django app suggests that there is a way to add a csrf token to a third party site, and this would make #csrf_exempt unnecessary.
Which of these approaches is right? If my understanding of csrf is correct it makes sense to me that there is no risk of csrf without user authentication. Such an attack would not be able to achieve anything, since the third party making the attack could not perform any task they can’t perform already?
The importance of csrf protection is emphasised so much in the learning resources, I just want to be really sure I don’t need it before I turn it off!
Thanks for your help!
Your analysis is right.
CSRF protections are necessary because browsers send the target domain's cookies regardless of what domain makes the request. If your server doesn't make use of cookies (for authentication or anything else) then you are not at risk for the kinds of attacks CSRF is designed to prevent.
Some of the answers to Do CSRF attacks apply to API's? suggest that a csrf token is not necessary if there is no user auth. However, some of the answers also suggest that there should be some other form of authentication in place instead.
There are, of course, pros and cons of different forms of authentication (specifically, cookie-and-session-based vs header-and-token-based), but I don't see anyone suggesting that you should use some other form of authentication instead of no authentication at all.
I have done a few mobile apps using django as my backend, and now I am working on a chrome extension. I want my users to be able to send POST requests up to the server using the app/extension but is there a way to do it without first asking the server for a CSRF token? It just saves the app from making two requests every time we want to submit data. For example, I want to update my profile on my social media app or update a wallet from a chrome extension. It would be nice to open up the profile view input the data and push it to the server. It's less sleek if I have to open the profile, then wait for it to grab a token from the server and then I can submit the data. Is there another way to do this? Or am I stuck making multiple requests every time I want to submit data?
Also, a little clarification, CSRF prevents sites from submitting forms with user's data. But what is to stop me from making a site that uses ajax or something to grab the real site and steal the CSRF token and then paste that into my cross site request form? I feel like there is a loophole here. I know that I am not quite understanding this all the way.
You can, and should, make any API endpoint CSRF exempt.
Django offers the csrf_exempt decorator for exactly this, see https://docs.djangoproject.com/en/dev/ref/contrib/csrf/#django.views.decorators.csrf.csrf_exempt.
Also CSRF is intended to prevent unintended actions being performed via GET request forgeries. It is not intended to make it impossible for an automated system to submit forms, there are captchas for that.
As for what prevents you from using AJAX to grab the whole site and extract the token is something called the Same-Origin Policy. This is implemented by the browser and prevents any AJAX call from returning data when the target of the AJAX call is a different domain without the correct headers set. (I'm not entirely sure what sandboxing is applied to chrome extensions concerning this). As such it will, or at least should, fail to get data via AJAX for normal websites, e.g. a profile page. If you want to interact with third party websites you should look into whether or not they offer an API.