-
Notifications
You must be signed in to change notification settings - Fork 0
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
danlivings-dxw
wants to merge
13
commits into
feature/common-app-config
Choose a base branch
from
feature/103-add-user-authentication
base: feature/common-app-config
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Implement authentication for Towtruck #130
danlivings-dxw
wants to merge
13
commits into
feature/common-app-config
from
feature/103-add-user-authentication
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
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.
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).
594b33e
to
2619e8a
Compare
This was referenced Mar 7, 2025
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
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:
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.