Feature HTTP Basic Authentication support #226 #937

[jln-brtn]

Community Contribution License Agreement

By creating this pull request, I grant the project maintainers an unlimited, perpetual license to use, modify, and redistribute these contributions under any terms they choose, including both the AGPLv3 and the Fossorial Commercial license terms. I represent that I have the right to grant this license for all contributed content.

Description

This feature introduces support for the 'Basic' HTTP Authentication Scheme (RFC 7617) to allow access to a protected resource. As described in #226 and #937, the primary goal is to provide an alternative to Pangolin's standard SSO authentication, which requires user interaction with a graphical interface. Supporting header-based authentication enables third-party systems and headless clients to bypass the interactive login flow by providing credentials directly in the request header.

Currently, when an unauthenticated user tries to access a resource managed by Pangolin (e.g., a Jellyfin server at https://play.example.com), they are redirected to a login page. This flow is incompatible with headless clients, such as the Jellyfin mobile application, which cannot render the web login page.

The existing workaround involves creating filtering rules to allow specific URL paths to bypass authentication. This approach is insecure, as it exposes endpoints publicly, and brittle, as it requires maintaining an exhaustive list of all necessary API routes.

This feature allows users to enable Basic Authentication for a resource through the management interface. When configuring the resource, the user can add header-based authentication by specifying a username and password.

Once configured, a client can authenticate by embedding the credentials in the URL (e.g., https://user:[email protected]) or by providing them in the Authorization header. Pangolin will identify and validate these credentials, allowing the request to proceed to the backend resource without any GUI interaction.

How to test?

• Navigate to the management UI and edit a resource.
• Enable the new "Header Authentication" option.
• Enter a desired username and password and save the configuration.
• Send a request to the resource's URL using cURL with the correct credentials: curl -u "username:password" https://play.example.com. The request should be successful (e.g., HTTP 200 OK) and the resource content should be returned.
• Send a request with incorrect credentials: curl -u "username:wrongpassword" https://play.example.com. The request should be redirected to the standard pangolin login page.
• Send a request without credentials from a new browser session. The request should be redirected to the traditional pangolin login.
• Remove the "Header Authentication" option and send a request with the correct credentials. The request should be redirected to the traditional pangolin login.

Points of attention

While it's my first contribution to this project, some minor point should be check :

• I've modified the database by adding a table. The schema.ts have been modified, from both pg and sqlite. Anything to do for migration ? (not familiar with drizzle)
• verify-session method have been modified. Have I placed it correctly in order to maintain consistency with other validations (such as rules, for example) ?
• I used cache in order to speed up verification (due to the hashing function), is any security issue ? I think the cache is a major factor because a non-cached authentication took 40 ms locally, whereas with the cache it took 12 ms.

Huge thanks to @AstralDestiny which help me to set up the local development environment

[oschwartz10612]

Hi @jln-brtn this looks awesome and I am sorry for the delay in reviewing!

We will need a custom migration file in the migrations scripts directory for the version this releases under with sql commands to create the table. This can be generated using drizzle but we can handle it!

Things generally look good. I will test ASAP and provide more feedback / merge.

[oschwartz10612]

Oh we will also want to add this to the new blueprints so it can be edited with that as well. This can be found in server/lib/blueprints. Should be pretty straightforward I think but I can assist with this as well.

[oschwartz10612]

Things look good! I rebased and added the blueprint support!

I used cache in order to speed up verification (due to the hashing function), is any security issue ? I think the cache is a major factor because a non-cached authentication took 40 ms locally, whereas with the cache it took 12 ms.

I think this is okay? We do it with other methods. I assume the biggest danger is that it gets removed from the database but for some time it persists in the cache and still allows access. I think this is an okay trade off with the cache being 5 seconds only.