Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Implement authentication for Towtruck #130

Open
wants to merge 13 commits into
base: feature/common-app-config
Choose a base branch
from

Conversation

danlivings-dxw
Copy link
Contributor

This PR introduces the concept of users to Towtruck.

Currently, Towtruck does not require any proof of identity to look at the dashboard. This is a minor security risk, as it displays both public and private repositories. Even divulging the existence of private repos is considered a leak of sensitive information, but it also contains details about dependencies - including specifically those that are out of date and potentially vulnerable.

To address this, a user must be able to prove that they have a right to view this information. To do this, this PR provides two methods:

  • GitHub OAuth: a user can prove that they can view this information by logging into a GitHub account that is a member of the dxw org.
  • Username and password: a user can prove they can view this information by providing a correct username and password combination.

These are designed to be used in two different contexts - in production, GitHub OAuth should be preferred, and username/password should be limited to local development and testing. To discourage the use of password logins, no user management interface is provided - these users are currently only created through the use of a seed script.

A previous attempt at implementing authentication can be seen at #73, although it ran into issues around end-to-end testing. This PR is a full rewrite of this functionality built from the ground up with end-to-end testing in mind. Accordingly, the end-to-end tests have been significantly expanded, including testing of the authentication functionality.

This allows us to process JWT tokens, which we can use to check whether
a user is logged in.
Currently this is an extremely basic check - that the user has a GitHub
account that they can authorise. It doesn't yet check whether they have
access to any particular org.
Storing users in the database allows for organisation access to be
decoupled from the GitHub API, which is particularly useful when running
tests in the CI pipeline, but also reduces the number of requests the
application makes overall.
@danlivings-dxw danlivings-dxw linked an issue Mar 7, 2025 that may be closed by this pull request
This provides a `User` object that can be used within the application
code as well as some abstractions over the database layer for retrieving
and saving users.
This will mainly be used for end-to-end testing in the CI pipeline to
avoid having to authenticate with GitHub, although this implementation
corresponds to best practices, in that passwords are not stored in
plaintext, a salt is used, and hashes are computed using a secure
algorithm (SHA512).

Currently new users are not created directly within the application,
although a unique random salt should be provided for each user when this
is implemented.
This involves creating a custom middleware to set the current user on
the request, which runs after the JWT auth is verified, allowing the
application to retrieve the name of the current user.

If the current user is set, the templating engine will display a welcome
message to the user and also provide a link to log out. If clicked, the
server instructs the browser to immediately expire the token cookie,
with the effect of logging them out.

To make sure that this works with GitHub OAuth, the GitHub login
callback now stores a `User` object representing the GitHub user in the
database, using the organisations that they're subscribed to at the time
of login.
The root path `/` now displays a list of organisations using Towtruck
that the user is a member of. Items in the list link to
organisation-specific dashboards available at `/orgs/:org`. Users that
aren't members of an organisation will see a 404 page, preventing the
unauthorised access to information about private repositories.
This allows for discovery of multiple setup files, rather than manually
defining each one.
This sets up steps to login as the three test users and store the auth
token cookie. These can be used to run a test as a user by calling
`test.use({ storageState: getAuthFile('<username>') });` before the test
or within a `describe` block.
This commit introduces two changes:
1. The repo data has been de-dxwified: the name "dxw" has been replaced
   with a generic name to demonstrate that Towtruck is not coupled to
   the specific org.
2. Data associated with the new 'user' scope has been added: the test
   database has three test users that can log in with a username and
   password, and a dummy GitHub user (who should not be able to login).
Several new end-to-end tests have been introduced to expand the
confidence we have in the overall functioning of Towtruck, especially
considering that the application has grown significantly more complex.

Tests are now roughly scoped in their files according to the aspect of
the application being tested (e.g. logging in).
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add authentication
1 participant