I am currently using Oauth to allow a user to sign in through Foursquare, I then create a new session for this user. If the user is new to the system they are asked to sign in through Hunch, this can then generate a user profile based on information from both systems. I have them both signing in to each application separately, but how can I associate the user logged in with Foursquare to the one in Hunch.
My idea for it was to somehow create a reference to the session id in the user model, or use the session ID as a parameter for the hunch sign in but I'm not sure if this would be the best idea. Is there any other way in which I can create the association?
The easiest way to do this would be something like the following:
Send the user to foursquare to sign in
When the user returns, create a record in the datastore for them.
Send the user to Hunch to sign in, but include the ID of the record you created in step 2 in the continue URL.
When the user returns, use the ID embedded in the URL to add the user's Hunch info to their user record.
You can create a parent association so that SiteUser is the parent of FoursquareAuth and HunchAuth.
When the user first logs in with Foursquare you create the SiteUser model and then create the FoursquareAuth model with parent=just_created_user. Then when you send the user off to authenticate through hunch you include the user's id, or a session id in the callback parameter. When the callback happens you get the user's key and create HunchAuth with parent=previously_created_user.
The SiteUser model contains the combined information from both sources (name, location, last checkin, etc.). The *Auth models just contain whatever guaranteed unique identifiers are supplied by each provider (user_id, access_token, etc.).
This way, if you have the user object you can find either the Foursquare or the Hunch authentication data (using an ancestor filter), and you can find a user by loading any *Auth model and fetching its parent().
(note: I call the model SiteUser to not confuse it with the User object available in App Engine)
Related
I added authorization through social networks to my site. How can I find out that the user used exactly this authorization?
In the process of authorizing a user through a social network, I need to change the verified value in the database table, as well as add his photo to this table.
Note: I didn't rewrite the default user model, but extended it by creating a ForeignKey in the Profile table. This table stores information about the user (phone number, gender, etc.)
Note2: I'm using social-auth-app-django
It seems to me that I should implement a separate View for authorization on social networks in order to catch all the data I need. But what should it look like? I am new to this matter.
I am looking to generate a django authtoken for a non user object. previously I had easily generated auth tokens for user objects like this
email = request.data.get('email')
user = User.objects.get(email=email)
Token.objects.create(user=user)
but if I am trying this for non user object it is not getting generated.
device_id = request.data.get('device_id')
tablet = Table.objects.get(device_id=device_id)
Token.objects.create(user=tablet)
Here Table is simple model holding various device_ids.
I just want to generate an auth token for each tablet like we do for each user.
If you are linking devices to users, and need a "per device" token where a user has >1 device (e.g. desktop, tablet, phone, etc) that are logged in separately and where the tokens can be revoked, then look at the Knox App:
Django Knox (https://github.com/James1345/django-rest-knox)
Otherwise, authentication tokens are normally used to log in a user. If you don't have a user then they aren't much use as far as the standard infrastructure is concerned.
If you want something custom, then you'll have to write your own solution, which might include:
A custom middleware if:
you want/need to set request.device=, like request.user
you want a custom user object (below)
Decide if you want a "fake" user like DeviceUser
Implement the User interface (see AnonymousUser's example)
Has is_authenticated=True
Has permissions (?)
Has is_device_user=True so you can distinguish
Be really careful not to rely on request.user to have a user_id
Possibly a new Permission class (e.g. a new IsAuthenticated)
The main problem I see is with things that expect a non-anonymous User object (in request) to be a real user with a pk. If you are careful then this might not be too big an issue, but you'll need to start implementing to be sure how it affects you.
I'm trying to build a Django website that will be maintained and used by university students mainly. I need to restrict access to a few pages for certain approved students, but it would be very unmaintainable if I needed to create a new Django user for every student that wants to log in. Luckily, the university provides an API to check whether a username/password combination is correct. So I had the idea to create an authentication model complementary to Django's model, where users' university account can get approved by an admin, after which it is a valid login to view certain pages.
So essentially, some users may use a Django account (if they're in charge for the content of the website), and other users may just log in to view some pages with their uni account. For the uni account, the minimum amount of info should be stored (in other words, only the username is really required to approve certain users).
I can't seem to figure out how to build such a system in Django. I cannot use the standard User object because it stores data that is completely redundant, and I cannot substitute the user model because that would only make things incredibly complex. It seems reasonable to forget the User model altogether, but Authenticate needs to return a valid user. This makes me wonder, can I create regular Django users with as little information filled in as possible (dummy data except for the username), and then authenticate them with the API? Probably, but that hardly seems like a good idea.
To authenticate users using the university API, all you need to do is to write an authentication backend. You can then create a local user for these uni users the first time they login, since there is only two required fields: username and password. You can use set_unusable_password() so check_password() for this user will never return True.
The Django admin system is tightly coupled to the Django User object
described at the beginning of this document. For now, the best way to
deal with this is to create a Django User object for each user that
exists for your backend (e.g., in your LDAP directory, your external
SQL database, etc.) You can either write a script to do this in
advance, or your authenticate method can do it the first time a user
logs in.
I have been asked to introduce an unusual case and I'm wondering how others would go about it.
I have users in my Django application. The model is a standard user model, authentication. etc. Each one of of these site users can add their own contacts to the system. However my new requirement is to allow their contacts to set a password (if they want to to) so that they can login to their status page (belonging to that user).
So my question is how would you do this? I already have the contact table (which belongs to one user), I'm thinking of adding in a password (optional) field, but then I'm unsure how to handle the authentication for this as they are not my users but members of my users (if that make sense).
One way would be to create another user model for contacts inheriting from AbstractBaseUser. And then creating custom auth backend that would look in both models to login user. Finaly you would have to distinguish between standard user and contact user before every action.
That is if contact user and standard user differ significantly in your application.
Or you could just create custom user in your application, that would contain is_contact attribute. This would be used for both types of users. You would set that as AUTH_USER_MODEL in settings and check before every action for the is_contact attribute to determine the outcome. You could return 403 for the contact user if he tries to access what he's not suppose to.
Or if you use permissions in your application, you could set the contact user's persmissions only to view statuses of the users that added him as a contact and nothing else.
Essentially I am creating a webapp for a customer with a business that would allow customers of his business to be able to purchase specific things which I set up as entities. However, my customer wants to be able to have a specific page where he can post/upload images of his items, and based on:
Google App Engine - find out if a user is an administrator
-it seems I can't do an administrator login, so is there a way using the user model object to specify a specific page for a particular user login via a google account? So essentially I was thinking that I would create 2 different python and html pages one for the customers and one for the administrator/buiness owner. Depending on a specific login I would route accordingly. I am a relative newbie to Google App Engine, and have a short amount of experience with Python. The business owner created the app engine specific domain name and I was invited as a developer, so I am assuming he is considered the admin so I think I can use: https://developers.google.com/appengine/docs/python/users/adminusers
The thing I am uncertain about is whether images, strings, blobs, etc. associated with a particular entity when written will be displayed to two different files: user.py and admin.py. So I want the business owner to be able to post an item and the user to be able to see that same item.
What you're describing is basically an ACL (Access Control List), which is a mechanism for associating a user (a person or process) with a set of permissions (view, create, update, delete, etc.)
Within your application, you can create a new ACL model that stores a relationship between a User object and a set of permissions. Within each of your pages, check that the current user has the appropriate permission to perform the specified action on that page (e.g. an instance of the ACL model that pairs the current user with the permission you are checking).
You can abstract this further with a concept of "roles", which are a collection of permissions. For instance, you can create an "admin" role, with the permission to view the admin pages, and create or delete entities. The "customer" role may only have the ability to view entities.
Here's some example code that demonstrates how your app might use this:
class ACL(db.Model):
user = db.UserProperty()
permissions = db.ListProperty(str) # there are lots of other ways to store the permissions as well
After you've added an admin user, you'll have a row in the datastore that looks something like this:
User Permissions
admin#example.com ['ADMIN_VIEWER', 'ADMIN_EDITOR']
Within your code on your admin page you can do:
user = users.get_current_user()
acl = db.GqlQuery("SELECT * FROM ACL WHERE user = :1", user).get()
if 'ADMIN_VIEWER' in acl.permissions:
# continue
else:
# unauthorized
You can put the current user's ACL in memcache if you anticipate doing many lookups.