Allow server connection url with embedded basic http access authentication scheme #491

New Issue

2026-04-24T23:25:59+02:00

adam commented

2026-04-24 23:25:59 +02:00

Originally created by @altmoola on GitHub (Mar 16, 2023).

Allow https://username:password@abs.domain.tld format urls for the server. Add the following to all http requests if a server url with basic authentication is supplied. To ensure credentials are encrypted, only allow the url if the scheme is https.

Authorization: Basic username:password (credentials Base64 encoded)

Originally created by @altmoola on GitHub (Mar 16, 2023). Allow https://username:password@abs.domain.tld format urls for the server. Add the following to all http requests if a server url with basic authentication is supplied. To ensure credentials are encrypted, only allow the url if the scheme is `https`. `Authorization: Basic username:password` (credentials Base64 encoded) ![image](https://user-images.githubusercontent.com/15036268/225662410-9425ae40-336c-431e-be37-65c2d2ec262b.png)

adam added the enhancement label 2026-04-24 23:25:59 +02:00

adam commented

2026-04-24 23:26:00 +02:00

@advplyr commented on GitHub (Mar 19, 2023):

Related to #254

@advplyr commented on GitHub (Mar 19, 2023): Related to #254

adam commented

2026-04-24 23:26:00 +02:00

@bengalih commented on GitHub (May 24, 2025):

Is there any movement on this? I host about a dozen services through my nignx proxy.
I require basic http(s) authentication before even presenting the particular apps login screen.
All remote apps I have seem to support the ability to provide the username:password@ syntax.
ABS seems to be the standout.

Thanks!

@bengalih commented on GitHub (May 24, 2025): Is there any movement on this? I host about a dozen services through my nignx proxy. I require basic http(s) authentication before even presenting the particular apps login screen. All remote apps I have seem to support the ability to provide the username:password@ syntax. ABS seems to be the standout. Thanks!

adam commented

2026-04-24 23:26:00 +02:00

@advplyr commented on GitHub (May 24, 2025):

Is there any movement on this? I host about a dozen services through my nignx proxy. I require basic http(s) authentication before even presenting the particular apps login screen. All remote apps I have seem to support the ability to provide the username:password@ syntax. ABS seems to be the standout.

Thanks!

Can you share some of the apps with this? I don't really understand the purpose of that.

@advplyr commented on GitHub (May 24, 2025): > Is there any movement on this? I host about a dozen services through my nignx proxy. I require basic http(s) authentication before even presenting the particular apps login screen. All remote apps I have seem to support the ability to provide the username:password@ syntax. ABS seems to be the standout. > > Thanks! Can you share some of the apps with this? I don't really understand the purpose of that.

adam commented

2026-04-24 23:26:02 +02:00

@bengalih commented on GitHub (May 24, 2025):

Yeah, no problem. Two big ones are:

https://play.google.com/store/apps/details?id=com.kevinforeman.nzb360&hl=en_US - supports multiple back-end services
https://play.google.com/store/apps/details?id=org.transdroid.lite&hl=en_US

When you say you don't understand the purpose - you mean why someone would use basic authentication over https://?
Basically it is another level of protection before being presented with whatever authentication mechanism a specific app requires. I use this on my reverse proxy (NGINX) so that someone won't even be presented with a logon screen until passing basic authentication.

Now there is a certain level of insecurity here since the full string may be cached in logs/history/etc. But usually all those clients and system are under my control in this case, so it is a risk I am willing to take to protect from outside.

For services that I can't use this format with, I have two options:

First connect via VPN to my network, then use as local. This is what I need to do when accessing just the WebUI's of my services if I don't want to keep getting prompted for creds (since I don't usually bookmark the sites with the creds in them).
And this is where I mis-spoke on my last post. Not all my services rely on this. Some services which only go through specific endpoints I have sometimes allowed through directly. For instance /json or /api. This allows me to go direct to those endpoints and still have to authenticate with an API, etc, while still blocking the main WebUI authentication form.

In fact, I was able to sort of mitigate my issue. While I already allowed through /api at the top level, I find that allowing through /ping and /socket.io are the 3 endpoints that ABS-app requires to make the connection. So I am able to use the app this way while still requiring the basic auth through the standard https:// abs webUI.

As far as implementing, you do not need to actually pass the username:password@ in the https:// string. In fact it would be more secure to create some additional settings fields for user/pass and then send them in the header:

Authorization: Basic base64(username:password)

I think the OP is suggesting something like this.

Does it need more explanation?

@bengalih commented on GitHub (May 24, 2025): Yeah, no problem. Two big ones are: https://play.google.com/store/apps/details?id=com.kevinforeman.nzb360&hl=en_US - supports multiple back-end services https://play.google.com/store/apps/details?id=org.transdroid.lite&hl=en_US When you say you don't understand the purpose - you mean why someone would use basic authentication over https://? Basically it is another level of protection before being presented with whatever authentication mechanism a specific app requires. I use this on my reverse proxy (NGINX) so that someone won't even be presented with a logon screen until passing basic authentication. Now there is a certain level of insecurity here since the full string may be cached in logs/history/etc. But usually all those clients and system are under my control in this case, so it is a risk I am willing to take to protect from outside. For services that I can't use this format with, I have two options: 1) First connect via VPN to my network, then use as local. This is what I need to do when accessing just the WebUI's of my services if I don't want to keep getting prompted for creds (since I don't usually bookmark the sites with the creds in them). 2) And this is where I mis-spoke on my last post. Not *all* my services rely on this. Some services which only go through specific endpoints I have sometimes allowed through directly. For instance /json or /api. This allows me to go direct to those endpoints and still have to authenticate with an API, etc, while still blocking the main WebUI authentication form. In fact, I was able to sort of mitigate my issue. While I already allowed through /api at the top level, I find that allowing through /ping and /socket.io are the 3 endpoints that ABS-app requires to make the connection. So I am able to use the app this way while still requiring the basic auth through the standard https:// abs webUI. As far as implementing, you do not need to actually pass the username:password@ in the https:// string. In fact it would be more secure to create some additional settings fields for user/pass and then send them in the header: `Authorization: Basic base64(username:password)` I think the OP is suggesting something like this. Does it need more explanation?

adam commented

2026-04-24 23:26:04 +02:00

@martynhaigh commented on GitHub (Jun 15, 2025):

Just want to chip in and request this feature too. I'm hosting behind a traefik instance and need basic auth to be able to access my services

@martynhaigh commented on GitHub (Jun 15, 2025): Just want to chip in and request this feature too. I'm hosting behind a traefik instance and need basic auth to be able to access my services

Sign in to join this conversation.

1 Participants

Notifications

Due Date

No due date set.

Dependencies

No dependencies set.

Reference: starred/audiobookshelf-app#491