Last year I built and launched AquaristSpecies.net using Django. It’s a site built for aquarium hobbyists to share species they keep and find other aquarists keeping species they’re interested in keeping.
One challenge is the fact that many of the seasoned veterans of the hobby are non-techies who can barely use their cell phones and don’t want to ‘create accounts’ and log onto sites to do things even if they’re interested.
In this year’s feature update I’d like to add a ‘Manage User By Proxy’ feature. In other words, I’d like Admins to be able to manage a group of users they talk with, visit, know personally etc. without forcing these users to create an account and deal with ‘technology’.
So for example, if an Admin is maintaining a species with several other hobbyists, I’d like the Admin to be able to ‘create a proxy account’ for ‘Joe Somebody’ and ‘Pam Somebody’ and be able to switch into a mode where all activity and db entries use the ‘Joe’ or ‘Pam’ proxy user.
Seems like an obvious Custom User Model kind of implementation, but there’s a lot in the weeds and I thought it would be smart to ask this group for advice. Obviously I don’t want account verification, etc. but I probably do want email to default to the ‘Proxy Owner’.
Microsoft Copilot suggests the obvious User Model starting point and outlines:
**Extend the User Model** - Create a custom user model or extend the existing one to include a reference to the proxy user
**Authorization Logic** - Implement logic to check if the current user has permissions to act as a proxy user.
**Middleware** - Use middleware to switch the user context when acting as a proxy user.
**Views and Forms** - Update views and forms to handle proxy user actions.
I’m sure an expert could implement this without too much trouble, but I’m still a newbie. Be helpful to hear any key insights or pros/cons on different ways to approach this.
Are “Joe” or “Pam” “Somebody” going to be logging on at all? If not, then there’s no reason to represent them within the User model all. I would approach this as if “Joe” and “Pam” were more like customers.
The “Admin” would be the real accounts, with perhaps a session setting to indicate the active customer.
There are other ways of handling it. The choices depend upon how long this “proxy usage” is supposed to remain active.
Once an admin indicates that they are proxying “Joe”, when do they stop doing this? When they log out? When they change users? When they close their browser? Should they be able to switch computers and expect to still be proxying the same user without having to select them again?
You would need a much more solid definition of what proxying a user really entails before you can make an informed decision regarding the implementation.
If you do decide that these need to be actual User accounts, then maybe something like Django Hijack (which I’ve never used) would be the simplest way of implementing “Admin user acts on behalf of other user”.
But as Ken says, that might not be the best approach anyway.
I would guess that the real people behind ‘proxy users’ would - at least occassionaly - see and hear about site activity that eventuallyl motivates them to make an account. Thinking about that scenario, it would require a migration of some form anyway so writing an admin tool to transfer the proxy user’s db entries to a newly added user wouldn’t be difficult or problematic.
I don’t see a need to preserve the proxy user state for an extended time. Basically they would enter the proxy user mode, add or update species kept by the aquarist, and be done. Probably would make sense to emphasize the proxy state visually so it’s easy to spot so they don’t mix up user entries. It might be acceptable to end the proxy session after a certain timeout. Certainly closing the browser or using another computer/device would restore the non-proxy user state.
This is one of my key questions. Are true proxy ‘user accounts’ really needed? Seems like the elegant approach, but user accounts come with a lot of supporting features so it would need to be carefully done.
I will have a look at Django Hijack. It’s come up before in my searches.
Could be simpler to add a list of ‘proxy users’ to the user class. Would like to avoid messy ‘proxy status checking code’ sprinkled throughout the project, but since the primary use case is adding/editing aquarist species this may prove narrow enough in scope to be acceptable?
Actually, there wouldn’t need to be any work done at all.
Assume for the moment that instead of a “proxy user”, you identify an “owner” of this data. The current User is always working with the data associated with an Owner - which may be themselves. All operations are performed for the benefit of an Owner, not a User.
Any given User can be granted rights to work with one or more Owner.
When these real people decide to create an account, they are assigned permissions to the Owner that represents themselves, and have no alternatives to select from. No migration or data changes are necessary in this case, unless there’s the desire to remove the ability of an “admin” to work on behalf of that Owner.
And, there’s no requirement to go messing around with who the current User is.