I am working on SPA AngularJS application which allows users to collaborate on projects and stores history of edits for each user. The requirement is to allow unauthenticated users to manipulate data too. Once the user registers, I need to associate her history of edits with the newly created account. The backend is Django.
What is the best option to track actions of anonymous users?
I can create “anonymous” user at the firs visit, issue JWT, store it in the browser and use to track all the user’s activity. Later on when registering user, just update her profile.
The drawback is that there is a potential to get a lot of orphaned users that need to be periodically cleaned up.
This is similar to https://github.com/danfairs/django-lazysignup, but adapted to work with https://github.com/GetBlimp/django-rest-framework-jwt.
Use JWT or cookie to track user session. Allow using session identifier instead of user key to track user’s activity. When creating real user update all references to the session with user’s pk.
Anything else?
From my experience go for solution 1. The orphan user is often not a problem because from business plan point of view it's user and the more is better.
Also having only a notion of user is really simpler. They are users who haven't fully completed their profile that's all.
Related
I have an application and I use Cognito + Identity provider to use google accounts as my users. In Cognito, I have several groups, and in my application itself admin users can add users to groups, remove them from groups, and so on. The thing is, for these changes in the user to be reflected, the affected user needs to logout and in again in the application.
Having a new token fetched on every page load/request does not seem like a good practice. Therefore, I was looking for a Cognito function that would allow me to log a certain user from all it's active sessions. I looked for functions such as logout and revoke, but they require that I have the affected user's access token - which I obviously don't. After that I started playing around with other functions that could have the same effect, such as AdminForgetDevice - I thought that by forgetting a device maybe Cognito would log you out, but that is just used for 2FA, which my application doesn't support.
Seems to me a pretty basic thing what I'm trying to do, and kind of impossible to think that Cognito doesn't support it. Am I asking the wrong question? Is there an endpoint to accomplish this, or a different token-retrieval approach that I should use? I just want to make sure that if a user's groups were changed, those changes reflect immediately. My approach right now is forcing all that user's sessions to end.
I reached out to AWS support asking about this, and their official answer is that Cognito has no action to end all sessions of a specific user immediately. But I came to a solution on my own. You have two options:
1. User global signout and wait 1 hour until the user session is expired.
Not a fan of this solution. If you removed access from a user, makes no sense that the user can still use their old permissions for an hour.
2. Make your interface aware that the user should be logged out and use the logout function
This is the approach I'm going with. The moment an administrator changes a user's permissions, I am creating a notification for that user. The interface, once the user accesses it, know that there have been changes to that user because of the notification. The interface, then, in possession of the user's accessToken, can simply call the logout function.
I have a new public-facing Django/PostgreSQL-based web site that requires users to create a new username/password and then fill out a profile that requires three more screens (forms) after the initial username/password page to complete their membership. As you would expect, I have a small number of users that don't complete the entire signup process leaving me with abandoned user IDs. Do either Django and/or PostgreSQL provide any convenient means of recovering and reusing these abandoned user IDs?
In the context of a e-health related service, the end-users (health operators, doctors and physiotherapists) working in the same physical environment and sharing just one client PC to interact with my backend, asked me to provide them with a mechanism to quickly switch among different accounts (security is not a concern most of the time because they are used to work within a LAN but, occasionally, they might work from remote clients, so I must keep an authentication/authorization backend in place). They would log in just once and then, before using the web application, would select their logged-in account from a combobox (sort-of).
The UI model might be the same as in GMail where it's possible to keep multiple logged-in user accounts and switch between them through the account selector in the top right corner.
I'm no django-authentication expert, so I am not able to even tell whether this is possible in the context of a django based app.
Does anyone know of any ready-made app/middleware to get this done? Or maybe point me in the right direction if I have to extend or modify existing code?
Thanks a lot.
I haven't looked for any existing solution for this, so this is how I would go about it from scratch.
You'd need to add storage to the user session to hold multiple users. Currently it looks much like:
{'_auth_user_backend': 'membership.auth_backends.MyCustomAuthenticationBackend',
'_auth_user_hash': 'e2c8ecf1e7ecdbd<snip>',
'_auth_user_id': '3806'}
and I would add an array to the session:
logged_in_users = [{'_auth_user_backend': ... }, {}, {}] # one auth dict per user
Then when you "switch users", edit the session object to move that user's auth details (id, hash and backend) into the top-level ones in the session.
You'll also have to write a custom login function that stores the login into the logged_in_users array, and takes out the bit in the current login function that flushes your session if the key is the same as the session of a different logged in user. Similarly, you'll need to think what happens when you logout.
I'm using Ember 2.3 with Ember Simple Auth 1.0 and am wondering if anyone had any suggestions on the best approach to handle the following situation:
With the particular industry my platform serves, most staff are actually independent contractors and therefore could belong to multiple businesses. With that said, I have some specific requirements that I'm trying to address:
Avoid having to create a separate account with separate credentials for each business the staff member belongs to.
Allow credentials to be revoked at any time for a particular account.
Allow for account-level permissions.
Make it simple to switch accounts from inside the application without having to fully-reauthenticate.
To achieve this, my initial implementation is based around issuing a single JWT (using ember-simple-auth-token) for each user account. The proposed authentication flow would be as follows:
User logs in with username and password
System authenticates and if credentials are valid, return a token for each account.
If the system returns no tokens, return an error.
If the system returns a single token, use that token by default and redirect to the authenticated area of the site.
If the system returns more than one token, display a list of the accounts associated with those tokens and allow the user to choose the one in which they will be assuming the role of at that point.
What to do when the system returns more than one token is where I have questions:
Is there a way to "intercept" to allow the user to choose which account/token to use before ESA commits the token to the session in local storage?
If I want the user to be able to switch accounts, is it just a matter of swapping out the token value in local storage?
If there's anything else I should consider, I'd appreciate the feedback. If you also happen to think this is a terrible approach and have some feedback, I'd absolutely love it.
Cheers.
From ESA's perspective the user would be authenticated when the backend responds with one or more tokens (you'll have to implement a custom authenticator and authorizer of course). The fact that the session actually contains multiple tokens for multiple accounts isn't relevant for ESA really - that would be sth. that you'd need to handle in your application code instead.
Once the session is authenticated with one or more tokens, you can access them via the session's data.authenticated property, e.g. this.get('session.data.authenticated.tokens') etc. You could store the currently active account the user wants to use in the session's non-authenticated area, e.g. this.get('session.data').set('activeToken', 'whatever').
I am creating a saas, software as a service site with django.
Due to the project requirements the users are inside schemas/tenants, for that im using the fantastic django-tenant-schemas app, one user can have accounts inside different schemas (they share username and password) ... i want to let the user move throught the different schemas they are in more or less freely ... for that i have created a view where the user can select on what schema he wants to be on.
When i use an application wide cookie session that is when i have the cookie setting as ".domain.ext" (django documentation) that works fine but its NOT the behaviour we really want for our application.
What we really need is to be able to have different versions of the app on different browser tabs.
So we have to set the cookie configuration to "domain.ext", then everything breaks because the original view is on one tenant and the next view (where the just logged user really belongs) is inside other tenant then the old cookie is deleted.
So the question is how can i programmatically set the cookie correctly on the new view so the user that really belongs to that tenat is still authenticated.
Or is there any alternative approach we could use for that? Any examples?
EDIT TO CLARIFY as demanded:
Person A belongs to 2 schemas SH1 and SH2 on both of them he has the same username and password.
On every password change the password hash is replicated on all the schemas they belong to so they dont have to remember specific passwords or usernames.
When the person is logged on SH1 the url will be sh1.domain.com when he is logged on SH2 the url will be sh2.domain.com
So lets say the person is now logged on schema SH1, he decides to switch to schema SH2, to be able to do that i need the user to still been authenticated so that view has to be on the SH1 schema, but then its redirected to the new schema force authenticating the user but since the cookie is set as domain specific (default django behaviour) when the user lands on the next url sh1.domain.com/whatever the previous cookie is deleted and thus he has to log in again to be able to access.
If I'm understanding correctly, you want the ability to have the behavior of a cross-domain cookie, but without actually using a cross-domain cookie.
The immediate answer that comes to mind is "well, use a cross-domain cookie". This is pretty much the vanilla example of a situation where you'd want to use use a cross-domain cookie. Engineering a complex solution so that you can avoid using the simple solution never ends well :-) Unless there's some other constraint in play that you haven't revealed, I'd start by questioning whether you shouldn't just be doing this the easy way.
However, assuming there is a good reason (and, frankly, I'd be interested to know what that is), the problem you're going to face is that browser security is essentially trying to stop you doing exactly what you're proposing. You want to know, from domain SH2, whether something has happened to a cookie set on domain SH1. That's exactly the situation that cookie security policies are designed to prevent.
The only way you're going to be able to work around this is to have a third party that can share knowledge. When user A logs into SH1, you do password authentication as normal - but you also post a flag somewhere that says "User A is now on SH1". When A logs into SH2, you post the corresponding flag. If A goes back to SH1, you check against the central source of truth, discover that they're currently on SH2, and force a login.
You probably could do this by manipulating cookies and session keys, but I suspect an easier way would be to use an Authentication backend. What you'll be writing is an authentication backend that is very similar to Django's own backend - except that it will be making checks of cross-domain login status against the central source of truth.
How you implement that "source of truth" is up to you - an in memory cache, database table, or any other source of data will do. The key idea is that you're not trying to rewrite cookies so that the same cookie works on every site - you're keeping each site's cookies independent, but using Django's authentication infrastructure to keep the cookies synchronised as a user moves between domains.