I am using GAE's Python environment and Janrain in order to provide multiple ways to login in my service.
Based on login information I receive from Janrain, I create a google.appengine.api.User object and store it to the datastore. Is there a way to handle this new object with the built-in get_current_user()? I need to be able to determine whether the requester is logged in or not and who the user is.
No, you cannot use your custom user objects with the native GAE Users API.
You could use a sessions library to track whether or not the request is coming from a logged in user (and who that user is). I recommend gae-sessions. The source includes a demo which shows how to integrate the sessions library with Janrain/RPX.
Disclaimer: I wrote gae-sessions, but for an informative comparison of it with alternatives, read this article.
Related
I'm configuring MangoPay for my web application and it's now time for credit card registration. I'm using the python SDK that MangoPay recommends.
The workflow requires a CardRegistration to be created on the backend, which can be used to generate a form in the front end. On this form the user adds the credit card details, which are sent to a 3rd party tokenisation service and returned to the users front end. This token can be sent now to my backend and, added to the CardRegistration object, can be saved enabling the card for the user.
My issue is that I don't know how to store CardRegistration object between calls in the backend while I wait for the user to generate the token and return it.
Sessions can not be used, as the preregistration object contains sensitive data. To prove if it would have worked and I tried to use pickle but it raises a PicklingError, so serialization and storage doesn't look like an option either.
What should I look into? Is there some kind of design pattern I can use to store the object quickly for retrieval?
Currently I implemented a login routine for the website I am working on, according to This Tutorial.
Also I am not authenticating the user with djangos own system, because I am using authentication against the LDAP of my company (django-auth-ldap).
Currently I am using a general user to login to the database, which has universal access to all data, which also gives full access to any user logging in to the website.
To avoid that I would like to know how I can connect to the database as the individual user, who just logged in to the website.
Thanks in advance and sorry for bad english
Restricting user access to functionality and authenticating with the DB are handled separately in Django. You might be able to read the privileges of your users from the DB and map them to Django permissions but this is non-trivial (about Permissions see https://docs.djangoproject.com/en/2.1/topics/auth/default/#permissions-and-authorization).
In a UI/UX that has functionalities restricted depending on authorization, the frontend and backend need to be aware that permissions need to be checked and missing authorization needs to be communicated in some way or other to the user.
Example:
Users in group A are allowed to delete X. They see the "delete" button and there might also be an AJAX call that can delete X.
Users in group B are not allowed to delete X. They do not see the delete button and the AJAX call that can delete X needs to check for that permission and/or user group membership.
If you are only using a DB level authorization layer than - how would you know if the "delete" button should be displayed and for what to check in the AJAX call?
hi!
If I'm getting your problem correctly, the user you are creating is a Super User every time right?
Well if you are using Django auth.User model, you can just make User_object.is_super to False and then restrict the access of users though if-else in view! (User_object is the object of the auth.User model)
Does that made any sense?
//BTW, a side-note, a mistake I made while making my first custom user model: make sure to store your passwords hashed using Django hashes and salts!
I am starting web project that should be very flexible and modular and definitely will grow much in the future. As we plan to provide an api to other developers I started thinking that maybe it is a good idea to implement all the methods as api and provide functionality to use them remotely and internally.
For instance, say we want to extract all registered Users. So we design method in api, like get_all_users,which maybe available via REST or internal invocation. The problem is I cannot figure out how to distinguish access from internal usage and remote usage, as I should take into consideration also speed of internal invocation,code reusage and checking of user permissions(secret keys for api access, etc). What are the best practices? How to organize such API?
So to build the API, Tastypie or Piston. These let you write 'resources' (which are basically API versions of the views) - instead of returning httpresponses you just return objects which piston/tastypie convert into json or xml or yaml or whatever your favorite data-language is.
Securing the access: Consider decorating any resources which contain confidential information with the #login_required or #staff_member_required decorator as appropriate.
You might even want to go a step further and write a decorator to check that the staff user is using https (whereas you might allow a normal user to use any connection type).
If you have not considered it yet I recommend to use Tastypie to set up an API with django.
In order to distinguish between your internal and remote usage maybe you can simply design a different URL scheme.
I have created an application in python. And I am using extjs for the front-end.
Once a valid user logs in, I want to use the username of the logged in user for further transactions.
I wanted urgent help on how session management is to be done in python.
Thanks in advance.
You don't do "session management in Python". You do "session management in a framework, which may be implemented in Python".
A session can be implemented in many ways, but normally is implemented via Cookies. For example, Django (a Python framework), writes a cookie with a value called session containing a given string (say aabbccddeeff12345). For every request, Django checks whether the cookie exists, and if it does, it maps it to a user.
This is far from trivial. However, if you use Django (or most robust web frameworks in any language), this is completely transparent.
If you don't know what a cookie is, or are unfamiliar with web security, I don't think this is a problem that you should tackle yourself.
Use a framework, and understand it.
If you don't use a framework or if your framework doesn't provide session management, Beaker is a popular library do this.
Examples at https://beaker.groovie.org/sessions.html#using show how to store a username in the session object.
What are the pros and cons of using open id vs auth? Shoud I do both?
That depends whether you want to support Open ID. As to the reasons behind Open ID, in my view the most compelling one is that it avoids requiring your users to have an account just for your site, with all the hassle that involves (yet another username and password to remember).
If you decide you want to use Open ID, there's not need to choose between that and auth - use django-openid-auth, which adds Open ID support to the auth framework.
Definitely try and avoid using an Open ID implementation that doesn't plug into Django's auth framework - you'll lose a lot of the baked-in goodness of Django (model-level permissions etc).
OpenID and OAuth do different things. OpenID lets users log into your site. OAuth lets people give your site access to their data elsewhere. On the other side of the coin, OAuth gives you a secure way to let users access their data in your service from elsewhere.
If you implement OpenID, don't implement an OpenID producer. Everyone's already got an OpenID, whether they know it or not. Just consume openids from elsewhere. Migrating OpenIDs shouldn't be hard. Just make sure that a user account can connect via multiple OIDs, then they can add new ones as needed, and remove when they're done with them.
Edit: Just saw that you were talking about django auth, not oauth. Oops. The second paragraph still stands.