[Expo-tech] Troggle Login and user registration

Philip Sargent (Gmail) philip.sargent at gmail.com
Tue Jun 23 17:21:12 BST 2020


Troggle Login and user registration

see http://expo.survex.com/handbook/troggle/trogregistr.html for HTML
version of this.

 

Current position (June 2020)

---------------------------

Troggle has two "users", each with a password. They are managed by entirely
separate systems:

 

1.The user "expo" with the "cavey:beery" password on the website that gives
access to

-unpublished Austrian cave survey data from other cave clubs

-the online "Edit this page" capability and

-the online "Edit/enter this SVX file" capability.

 

2.The django administration account that gives direct online access to the
underlying database. This also (confusingly) has the username "expo".

 

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'

 

Why this is how it is

---------------------------

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 "<a
href="/expofiles/documents/troggle/troggle_paper.pdf" download>Troggle: a
novel system for cave exploration information management</a>", by Aaron
Curtis)

 

The django administrator account is built-in by default and created when the
database is initiated.

 

Why this is a problem

---------------------------

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.

 

Proposal #1

---------------------------

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 <a
href=https://docs.djangoproject.com/en/1.11/ref/settings/#file-upload-permis
sions">file upload permissions</a>

 

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.

 

Proposal #2

---------------------------

<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.

 

Go on to: Troggle architecture

Return to: Troggle intro

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.wookware.org/pipermail/expo-tech/attachments/20200623/d09e4b6e/attachment.htm>


More information about the Expo-tech mailing list