Skip to content

Instantly share code, notes, and snippets.

@Micrified

Micrified/permissions_users.md

Last active October 23, 2024 17:29
Show Gist options
  • Save Micrified/eff1e5232ab312a1346ffc37a434ee50 to your computer and use it in GitHub Desktop.
Save Micrified/eff1e5232ab312a1346ffc37a434ee50 to your computer and use it in GitHub Desktop.
Download ZIP
Permissions & Users
Raw
permissions_users.md

The following product requirements cause implementation challenges:

  1. Authentication via third party providers
  2. No storage of user credentials
  3. Access to the Wagtail CMS

The contradiction

A key stakeholder requirement is that users login via third-party services. This means:

  1. The credentials are handled and stored by the identity provider
  2. We only receive the user identity, and an affirmation of their authenticity.

This automatically poses a problem with the Wagtail CMS, which requires on its own accord:

  1. A user identity (username)
  2. A user credential (password)

Evidently, requirement (1) means we do not possess the password, with the exception of intercepting it via a form and a proxy network request (which, mind you, is not always possible). Furthermore, requirement (2) would be violated if we do capture and store the credential. This is not a hard requirement, but imposes a data handling burden which (1) was supposed to alleviate.

Should we decide not to violate (2) (which is not always possible), then we are left with determining what to do about (3). After all, it needs credentials too. We could use the client's identity as that for the CMS, which is fine. However, we cannot use the password, because we presume now to not store it.

A workaround might be to create separate credentials upon first-login with the third-party provider to use with the Wagtail CMS. However, this:

  1. Reintroduces (2), as these credentials (if improperly stored) would allow someone to impersonate the user on the site (albeit not on sister federated sites)
  2. Would be inaccessible after the user first log's out, given that the Django/Wagtail credential store auto-hashes the password, and the plaintext input would then be lost for the following re-authentication (unless you store it alongside in plaintext, which would be grossly irresponsible)

A workaround to this workaround would be to ask the user to maintain this separate set of credentials, but then that would invalidate (1), reducing it from a sign-in service to more of a register-referral service.

Actual solutions

The current solutions, as I see it are:

  1. Require users to maintain a separate set of credentials
  2. Provide a third party authentication module to Wagtail/Django, or write our own
  3. Implement a completely custom user model.
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment