I plan to use Google Accounts to authenticate users of my GAE app.
As i understand it, all owners of a gmail adress are considered equal and can be authentified.
My app providing a free trial mode that requires no login, i'm only interested to authentify my paying customers.
Maybe I miss something, but the only distinction between users mentioned in the docs is between admins/non admins.
What is the common practice to authenticate a specific class of users (in my case: paying users) in GAE?
Have a look at gae-biolerplate, it shows how to create a user class using different logins
If you want to have extra information on users use a new model ie UserExtra to add information
like ie paid etc
link to boilerplate
Related
After reading a lot of articles I came here to ask a question related to flask login with different types of users(two usermixin classes).
I have 2 types of users(as mentioned two user classes) - 1.Let’s call them regular users(email and password) 2.Social Network users(Facebook, Twitter, Google) and after a successful OAuth login with Facebook, Twitter and Google API I need to disable access to the profile page(regular users have access) and off course to stay logged and log them out later.
Here is the thing, I tried with https://pypi.org/project/Flask-Login-Multi/. Simple, I made 2 blueprints for auth.py where I defined logins for both types of users but it is not working(it crashes when I put #login_required)
I can provide my code here but I just want someone to help me with this if possible? Thanks in advance, regards.
There's a difference between authentication and authorization. Authentication determines who is allowed in and authorization determines what your users are allowed to see.
#login_required will handle authentication, but your question as asked deals with authorization. This means you will want to use #roles_accepted as well. Create multiple roles based on your intended behavior and then assign these users the appropriate role as needed. Using #roles_accepted will then deal with authorization, only allowing authorized users to access that route based on their role.
Flask principal with roles did the job and one more important thing to say is that I needed to define a login type in the session in order to have a conditional Flask login for both types of users(regular and social network).
I'm looking for a django app that would allow superusers to add, update, disable users, and to choose which group would this user belong to.
I have looked at different solutions:
Creating another admin site, with only user management registered to it.
django-user-accounts
django-userena
Those offer's very good solutions, but I'm looking for a simple interface for my users so I can't add another admin site.
I'm looking for simple create user, disable user function from the font-end of the system.
I suppose I can just go ahead and code this one but I wanted to check if there is any app that is available first.
Thanks in advance
For further reference so those who come across this post can benefit, I have searched for more than a week for a simple, and quick user management app.
There are two notable solutions advanced solutions first django-user-accounts it handles:
User activation
Forget Password
Sign up
Email confirmation
Signup tokens for private betas
Password reset
Account management (update account settings and change password)
Account deletion
second notable solution is django-userarena it handles
signup
signin
account editing
privacy settings
private messaging
having a back-office solution that only administrators are offered the ability to create a user, enable/disable them. I was only left with the solution of creating my own code, which is not bad, but I was hoping to find an easy, and tested solution.
Maybe if somebody is interested I can upload it someday.
Thanks
I am trying to figure out the best method of adding additional authorized application users through a web form accessed/maintained by a site admin user.
I am thinking that I want to check the get_current_user() against a list of authorized users entered by a user with site "admin" privileges (as in not application admin rights to the dashboard etc).
The examples Ive seen seem to indicate I should use email addresses. Is that the best practice or is there a way to use the email address to add the entire user property of a Google accout to my datastore as an authorized user? If so, are there any advantages to doing it?
A follow on question IF the entire user property has advantages is where I might find examples of how to implement this.
Generally speaking, web apps use email for authentication because you will need to communicate with the user, and email is the best/easiest way to do that, so it's a given that you're going to need an email address for them. Email addresses are also inherently unique, given that only one person can use an email account (unless they share, which they shouldn't).
I don't believe there is a way to query Google for Google+ records or somesuch. You could write something to do it, but there's really no advantage to importing all of that, except that you're going to creep them out because you have their picture and such.
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.
I need to add few more options for login and therefore need to customize create_login_url with some HTML code.
Is there a way to add on your code in default login screen of Google?
Environment: Python (Google App Engine)
I want to continue having the default Google ext class Users behavior in place.
You can't customize the login page. Allowing you to do so would introduce the possibility of XSS vulnerabilities, as well as making it harder for users to identify a legitimate login page.
If you want to provide for federated login, you may want to simply redirect users to an interstitial page that allows them to pick standard Google login, or one of a number of other services.
Nick Johnson recently released an alpha version of a WSGI middleware that you could use. The API is very similar to the standard Users API in app engine. It is a way to support auth via OpenID (something Alex Martelli suggested in his answer). Therefore you are able to support Google as Identity Provider as well as others. If you only want to support Google accounts for some reason, you could certainly only whitelist them though.
Nick's blog announcement also lists some things to consider (these might be deal-breakers for you):
Users are identified uniquely by their OpenID endpoint.
You can't construct a User object without specifying an OpenID URL.
Nicknames and email addresses are user-supplied, so they're not guaranteed unique or validated.
is_current_user_admin() is not yet implemented.
login: clauses in app.yaml are not affected by AEoid - they still authenticate using the regular Users API.
You might consider OpenID, through any of the various open-source app engine projects for the purpose, such as this one for Django.
You can't use the existing Users module with those (save perhaps with some serious hacking, but I have not attempted such feats and would not necessarily recommend them;-), but the various projects in question tend to offer usable replacements.
Making your own login pages is also not too hard with these approaches, of course, since you start with all the sources to the "OpenID consumer" you choose to use.
I don't know if all the domains you want to support are OpenID providers (though I don't see why any site supporting its own user logins wouldn't also be an OpenID provider -- it's easy and makes it more valuable for users to have logins on that site!-), but I hope this will take you some part of the way towards your goal!