We did option #1. No problem. But see 2025 footnote.
Troggle has two "users", each with a password. They are managed by entirely separate systems:
The first of these is managed by the 'django-registration' plug-in package which is in its second generation (it was rewritten entirely in 2015).
The second, the django administration user, is part of the core django Users/Groups system'django.contrib.auth'.
The original design of Troggle envisaged that expo cavers would have their own individual logins and manage their own accounts, which is what 'django-registration' is designed for. It easily handles the hundreds of accounts which would be necessary. (See " Troggle: a revised system for cave data management")
The django administrator account is built-in by default and created when the database is initiated.
The 'django-registration' plug-in package is responsible for nearly half the grief we have upgrading Troggle every time Django releases a new version (every 8 months or so). Even if we delay upgrading to the next Long Term Support (LTS) release that is still every 3 years and we have to do all the intermediate upgrades anyway.
This is a lot of effort, for just one user id. Especially when we have another, obligatory, user registration system already.
We edit troggle to create two ids when resetting: "expoadmin" (the django administrator) and "expo" (to have access to Austrian cave surveys and edit pages). These will both be created by the 'django.contrib.auth' system. Django gives us fine-grained access control settings for admin users so we can ensure that "expo" has the minimum necessary but has file upload permissions
We remove the 'django-registration' system entirely which reduces the attack surface of troggle - and the enforced deprecation/upgrade process certainly feels like an attack.
We change the name of the django administrator login to "expoadmin" as in proposal #1.
We write out own code to manage the "expo" user's capabilities and login GET/POST form (which would still have to use Django's form POST mechanisms because of session handling, CRSF security, cookies etc. etc.).
It might appear that proposal #2 would be on the road to eventually leaving Django, but because of the security issues it wouldn't really. This would all need to be rewritten again when we leave Django. So I think Proposal #1 will require less wasted work.
As troggle expands its capabilities we have been discovering that we could really use an individual user identification system.
So in January 2025 we introduced our own simple user registration system which stores the data as encrypted entries in JSON files, since we have a "file first & re-import" storage architecture whereas all other Django systems use a "database first" system.
This new registration system integrates with the experimental "expo signup" system whereby people we don't (yet) know can sign up to request to come on expo, and be easily distinguished from attendees from previous expos.