<p>Troggle has two "users", each with a password. They are managed by entirely separate systems:
<ol>
<li>The user "expo" with the "cavey:beery" password on the website that gives access to
<ul>
<li>unpublished Austrian cave survey data from other cave clubs
<li>the online "<ahref="../computing/hbmanual1.html">Edit this page</a>" capability and
<li>the online "<ahref="/survexfile/caves-1623/264/264.svx">Edit/enter this SVX file</a>" capability.
</ul>
<li>The django administration account that gives direct online access to the underlying database. This also (confusingly) has the username "expo".
</ol>
<p>The first of these is managed by the <ahref="https://django-registration.readthedocs.io/en/latest/upgrade.html">'django-registration'</a> plug-in package which is in its second generation (it was <ahref="https://www.b-list.org/weblog/2015/aug/13/django-registration/">rewritten entirely in 2015</a>).
<p> The second, the django administration user, is part of the core django Users/Groups system'<ahref="https://docs.djangoproject.com/en/1.11/ref/contrib/auth/">django.contrib.auth</a>'.
<p>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 "<ahref="/expofiles/documents/troggle/troggle2020.pdf"download>
Troggle: a revised system for cave data management</a>")
<p>The django administrator account is built-in by default and created when the database is initiated.
<h2>Why this is a problem</h2>
<p>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 <ahref="https://www.djangoproject.com/download/#supported-versions">Long Term Support (LTS)</a> release that is still every 3 years and we have to do all the intermediate upgrades anyway.
<p>This is a lot of effort, for just one user id. Especially when we have another, obligatory, user registration system already.
<h2>Proposal #1</h2>
<p>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 '<ahref="https://docs.djangoproject.com/en/1.11/ref/contrib/auth/">django.contrib.auth</a>' system.
Django gives us fine-grained access control settings for admin users so we can ensure that "expo" has the minimum necessary but has <ahref=https://docs.djangoproject.com/en/1.11/ref/settings/#file-upload-permissions">file upload permissions</a>
<p>We remove the 'django-registration' system entirely which reduces the <em>attack surface</em> of troggle - and the enforced deprecation/upgrade process certainly feels like an attack.
<h2>Proposal #2</h2>
<p>We change the name of the django administrator login to "expoadmin" as in proposal #1.
<p>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.).
<p>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.
