Hi Guys I am deploying a django project to elastic-beanstalk on AWS it currently is working fine, however I would like to know if it's a good or bad practice to allow the BrowsableAPIRenderer to be able to handle requests on my browser, I try to find anything related to it but there is really not too much documentation if not any at all. My App has a really strict permission policy, even when I access through the browsable API, it returns the following:
{
"detail": "Authentication credentials were not provided."
}
however it displays some sort of "information" about the endpoint. It's in that part where I find it difficult to define if I should allow it so that other developers can easily know what is going on, or on the other hand if it is a big risk to be accessible to the public.
You may find this question and its answers useful. Based on this answer, it is true that providing the BrowsableAPIRenderer would help development:
It provides simple UI interface to interact with model objects.
It can provide detailed debugging information.
A list of URLs can be shown in some API root
Based on your current settings, a user would at least need to log on either in DRF login page or Django ADMIN page to see and interact with your API.
You can enable the BrowsableAPI in development but disable it in your production settings following this answer.
In production, I wouldn't want other users, who have write permission, to interact with the APIs via BrowsableAPI. It will force the other users to use the front end app or other secure app to interact with APIs. That would provide a secure layer to forbid descriptive actions done using BrowsableAPI.
Related
I'm building an app with a Django backend, Angular frontend, and a REST API using Django REST Framework for Angular to consume. When I was still working out backend stuff with a vanilla frontend, I used the provided Django authentication to handle user auth- but now that I'm creating a REST based app, I'm not sure how to approach authentication.
Since all user data will be either retrieved or submitted via the API, should API authentication be enough? If so, do I need to remove the existing Django authentication middleware?
Right now, when I try to hit API endpoints on an early version of the app, I'm directed to what looks like the normal Django login form. If I enter a valid username and password, it doesn't work- just prompts to login again. Would removing the basic Django authentication prevent this? I want to be prompted to login, however I'm not sure how to handle that with these technologies.
The package django-rest-auth seems useful, and the same group makes an Angular module- but the docs don't go much past installation and the provided endpoints. Ultimately, I think the core of this question is: how do I entirely switch authentication away from what's provided by Django to something like django-rest-auth or one of the other 3rd party packages recommended by DRF?
edit: I made this comment below, but I realized that I need to figure out how combined auth will work. I'm not building a single page app, so individual basic pages will be served from Django, but each page will hit various API endpoints to retrieve the data it needs. Is there a way to have something like django-rest-auth handle all authentication?
To anyone that stumbles onto this question, I couldn't figure out how to make the hybrid approach work. Having Django serve pages that each contained API calls seemed OK, but I never saw any requests made to the API- I believe due to some other security issues. I'm sure it's possible, but I decided to go for the single page app implementation after all to make things simpler.
I want to implement a web service for an iOS application in django.
I need some kind of authentication, and I googled and heard good things about django token-api.
The only thing I don't understand, is how I make sure one authenticated user can not perform actions for another.
For example, If i have a view that has the #token-required, that only promises that a valid token has been sent, however someone can just change the PK in the request itself and make changes for another user.
How do I make sure the user who has the token, can only perform actions for himself?
On a very broad level, you need to distinguish between authentication and authorization. You can read this page as an example, or google it for more, but the basic distinction is that authentication determines that a user is who he says he is, while authorization determines what a certain user is able to see or do.
As you noted above, you can use the django-token-api to help with the authentication issue. But once you've determined that, you need to move to authorization. This is more an issue of permissions that you can see on a per-user (or per-group) basis for individual objects, views, etc.
As Ambroise noted in the comments, using an API framework can make this easier. Here is the django-rest-framework documentation for setting permissions once you have authenticated the user.
What is the best twitter auth plugin for Django. I do not understand why django-social-auth and django socialregistration suck so badly, but authentication to both facebook + twitter is not that hard and there seems to be no good django packages for either.
Please prove me wrong.
Thanks
I've attempted using allauth, but haven't gotten it to work.
This post lead me to it:
http://hackerluddite.wordpress.com/2011/05/17/review-of-4-django-social-auth-apps/
Let us know what you find that works.
I've also tested django-social-auth and django-socialregistration and they sucked. Things like easily fixed AttributeErrors caused by the software not being kept up to date with the latest Django. They also build upon the model that you authenticate with any of the social auth provider, but you still have to create a new account to login.
Then I tried Janrain and it is the best thing since sliced bread. You can either use it standalone because it is not so hard to integrate its javascript and json api yourself from scratch. Or use django-rpx-plus (RPX is the old name for Janrain) that provides some views and data structures to make integration even easier.
Using Janrain, it is easy to just let your users click on the google/twitter/facebook icon, click accept on the providers page shown in a popup and voila! logged in! The only downsides are the Janrain branding shown in the free version and that you have to rely on a third party for authentication.
Taking into account that I barely know python and am simply following the "hello-world" example here: http://code.google.com/appengine/docs/python/gettingstarted/
I'm unclear as to how I would: use a "MainHandler" class mapped to '/' as a welcome page, ask the user to login and then only allow logged-in users to access a "EditorHandler" class mapped to '/editor'
You've asked a very broad question, and provided no details about what (if any) framework you're planning to use to implement your app. I guess you are probably using webapp?
The basic idea would be to create a login url that you redirect the user to, or you provide to them. If you want them redirected to an edit page on your app, you can specify a dest_url when calling create_login_url:
users.create_login_url(dest_url='/edit')
Within your code you can secure your edit handler easily in app.yaml or with the '#login_required' decorator, depending on how you've setup your app.
This seems to work: http://appengine-cookbook.appspot.com/recipe/login-decorator
Although I dont understand the magic behind most of it, it's probably due to my lack of python skills.
Some comments on that article also point to more "native" solutions:
http://code.google.com/appengine/docs/python/tools/webapp/utilmodule.html
I'm working on an intranet django project (not using GAE) for a company that uses Google Apps for login. So I'd like my users to be able to log in to my django project using their google accounts login. OpenID seems appropriate, although maybe Oauth might work too?
I see a lot of similarly named libraries out there to connect django's auth system to external login systems:
django-authopenid - http://bitbucket.org/benoitc/django-authopenid
django-openid - http://github.com/simonw/django-openid
django-openidauth - http://code.google.com/p/django-openid-auth/
django-oauth - http://bitbucket.org/david/django-oauth
Here's what I'd like to do with the integration: Have users login with their google accounts, instead of the native django system. Keep django's permissions model for things like the admin system. So I think that means automatically creating a new user record in django the first time a new account we haven't seen before logs in.
Can anyone with experience using any of these projects advise me on which would work best? Or just advice on which are most active / functional if you've tried them? Thanks!
I finally got this working, so I'll answer my own question since the previous answers here were helpful but don't tell the whole story.
django-openid-auth is actually quite easy to set up and use. The README file is very clear. If you just want to use standard google accounts (i.e. #gmail.com addresses) then you configure it in settings.py with:
OPENID_SSO_SERVER_URL = 'https://www.google.com/accounts/o8/id'
But if you want to use a "google apps" account, i.e. hosted gmail at your own company's domain, then it's more complicated. I got my details from this question. To use your google apps accounts, configure your settings.py to:
OPENID_SSO_SERVER_URL = 'https://www.google.com/accounts/o8/site-xrds?hd=example.com'
# replace example.com with your hosted google apps domain
In the future this might just work, but today it probably won't. The problem is in python-openid which django-openid-auth relies on. The standard build of python-openid doesn't understand some protocol extensions google is using. (Why does google need to extend the protocol? Dig through http://groups.google.com/group/google-federated-login-api/web/openid-discovery-for-hosted-domains and report back. Good luck.) So you need to instead use adieu's patch to python-openid, which is available here:
http://github.com/adieu/python-openid
Install this over your existing python-openid. Now it should work.
Be careful with the OPENID_USE_AS_ADMIN_LOGIN setting since it requires you to have an openid user account which is 'staff' or 'superuser' to use admin which won't happen by default. So you'll need to do a 2-step process of enabling openid, logging in with your openid to create an account in django, then using your old admin account to mark your own openid account as superuser, and then disabling non-openid admin access.
One more thing: your domain admin might need to enable openid login for your domain before this will work. The control is at http://www.google.com/a/cpanel/example.com/SetupIdp
I've used django-openid-auth. Works fine, can create user account when signing first time. You also can associate openid login with user account in django admin panel.
I know this is a late answer, but I'm doing similar stuff and I just discovered django-socialregistration. which basically does OAuth, OpenID, Facebook Connect, etc. Unlike some of the other options it seems to be actively developed and used by a lot of projects.
I liked that Django socialregistration allowed me to plug in Google Accounts, Facebook, Yahoo and any other OpenID site pretty easily. You just need to give the provider as a link like so:
<img src="{{MEDIA_URL}}/images/yahoo.png"/>
They are all almost identical. I like django-authopenid. It has great documentation and is extremely easy to use. It'll do exactly what you want and do it better than django-openid (which is the only other one I have tried).
HTH