starred/audiobookshelf
1
0
Fork 0
mirror of https://github.com/advplyr/audiobookshelf.git synced 2026-05-30 23:40:40 +02:00
Code Issues 1.0k Packages Projects Releases 10 Wiki Activity

[Bug]: OAuth - Do not translate IssuerURL to IP-address(IPv4) - or make it optional #2725

New Issue
Closed
opened 2026-04-25 00:09:57 +02:00 by adam · 5 comments
adam commented 2026-04-25 00:09:57 +02:00
Owner
Copy Link
Copy Source

Originally created by @DaAndaDepp on GitHub (Apr 24, 2025).

What happened?

For users as myself whos ISP only provides an IPv6 connection and uses DS-lite to "tunnel" IPv4, the translation from an URL to an IPv4-address means, that we cannot connect back to a selfhosted OIDC service. Often directly accessing the IPv4-address isnt possible, because it only exists in the ISPs network. At least thats how i understand it.

What did you expect to happen?

Keeping the URL might allow connections.

Steps to reproduce the issue

  1. Have only IPv6
  2. Try accessing Issuer url e.g. with "Auto-populate"

Audiobookshelf version

v2.20.0

How are you running audiobookshelf?

Docker

What OS is your Audiobookshelf server hosted from?

Linux

If the issue is being seen in the UI, what browsers are you seeing the problem on?

None

Logs

[Auth] Failed to get openid configuration at "https://mydomain.com/webman/sso/.well-known/openid-configuration" AxiosError: connect ECONNREFUSED x.x.x.x:8843 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1611:16) { port: 8843, address: 'x.x.x.x', syscall: 'connect', code: 'ECONNREFUSED', errno: -111

Additional Notes

edited out my external IP ups

Originally created by @DaAndaDepp on GitHub (Apr 24, 2025). ### What happened? For users as myself whos ISP only provides an IPv6 connection and uses DS-lite to "tunnel" IPv4, the translation from an URL to an IPv4-address means, that we cannot connect back to a selfhosted OIDC service. Often directly accessing the IPv4-address isnt possible, because it only exists in the ISPs network. At least thats how i understand it. ### What did you expect to happen? Keeping the URL might allow connections. ### Steps to reproduce the issue 1. Have only IPv6 2. Try accessing Issuer url e.g. with "Auto-populate" ### Audiobookshelf version v2.20.0 ### How are you running audiobookshelf? Docker ### What OS is your Audiobookshelf server hosted from? Linux ### If the issue is being seen in the UI, what browsers are you seeing the problem on? None ### Logs ```shell [Auth] Failed to get openid configuration at "https://mydomain.com/webman/sso/.well-known/openid-configuration" AxiosError: connect ECONNREFUSED x.x.x.x:8843 at TCPConnectWrap.afterConnect [as oncomplete] (node:net:1611:16) { port: 8843, address: 'x.x.x.x', syscall: 'connect', code: 'ECONNREFUSED', errno: -111 ``` ### Additional Notes _edited out my external IP ups_
adam added the bug label 2026-04-25 00:09:57 +02:00
adam closed this issue 2026-04-25 00:09:57 +02:00
adam commented 2026-04-25 00:09:57 +02:00
Author
Owner
Copy Link
Copy Source

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

I don't understand this

@advplyr commented on GitHub (Apr 24, 2025): I don't understand this
adam commented 2026-04-25 00:09:57 +02:00
Author
Owner
Copy Link
Copy Source

@DaAndaDepp commented on GitHub (Apr 25, 2025):

I dont understand it either, but what suspect in my case and mb others is:

for discovery or callback the auth.js script is translating an URL like example.com to an IPv4 address like eg. 1.1.1.1 and mb a port

in my case the resolved IPv4, if accessed doesnt connect back to my server, because the ISP doesnt "route back" direct IP queries.
My ISP is only asinging IPv6 addresse(s) to my network and a "virtual" IPv4 address - this is called DS-lite tunnel IPv4 over IPv6
no clue how this works on a technical side

I can access everything fine through URLs
I cannot access anything through an IPv4 IP

I noticed in the logs, that the URL is translated into an IPv4 address. So i asume any request is directed to an IPv4 address which isnt accessable, instead of an URL which can be resolved.

sso.my.domain.com /ssooauth/ssouserinfo/ w/e-> browser shows the response just fine
I can setup my OIDC server, the login page opens just fine. i enter my credentials, evreything is fine, but the callback fails, which according to the logs calls an IPv4 address. same for the discovery

I also tried to setup a hostname, like xyz.local which is recognized in my LAN, but that fails too. my guess is, that the node.js (yes?) implementation in auth.js cannot resolve private networks, why would it...

Sorry, I am not very experienced with this kinda stuff

@DaAndaDepp commented on GitHub (Apr 25, 2025): I dont understand it either, but what suspect in my case and mb others is: for discovery or callback the auth.js script is translating an URL like example.com to an IPv4 address like eg. 1.1.1.1 and mb a port in my case the resolved IPv4, if accessed doesnt connect back to my server, because the ISP doesnt "route back" direct IP queries. My ISP is only asinging IPv6 addresse(s) to my network and a "virtual" IPv4 address - this is called DS-lite tunnel IPv4 over IPv6 no clue how this works on a technical side I can access everything fine through URLs I cannot access anything through an IPv4 IP I noticed in the logs, that the URL is translated into an IPv4 address. So i asume any request is directed to an IPv4 address which isnt accessable, instead of an URL which can be resolved. sso.my.domain.com /ssooauth/ssouserinfo/ w/e-> browser shows the response just fine I can setup my OIDC server, the login page opens just fine. i enter my credentials, evreything is fine, but the callback fails, which according to the logs calls an IPv4 address. same for the discovery I also tried to setup a hostname, like xyz.local which is recognized in my LAN, but that fails too. my guess is, that the node.js (yes?) implementation in auth.js cannot resolve private networks, why would it... Sorry, I am not very experienced with this kinda stuff
adam commented 2026-04-25 00:09:57 +02:00
Author
Owner
Copy Link
Copy Source

@Vito0912 commented on GitHub (Apr 28, 2025):

I am not particularly experienced with OAuth, so this issue may be specific to that context. However, I would like to highlight two points:

  1. Vodafone, atleast as of a few years ago when I tried, was relatively lenient in providing IPv4 addresses to customers at no additional cost. It may be worth a try to contact Vodafone directly and ask about obtaining an IPv4 address.

If that approach is unsuccessful (I am looking at you, Deutsche Glasfaser), another option is to purchase an inexpensive VPS—for instance, Ionos offers them for approximately 1€/month. You could then use a VPN solution such as WireGuard to route your traffic through the VPS and obtain IPv4 connectivity.

Addressing the root cause: a domain will generally attempt to resolve to an IPv4 address if an A record is configured. If your connection is DS-Lite only, there is little reason to set an A record in your DNS configuration. By omitting the A record, clients will be forced to resolve the domain via IPv6.

@Vito0912 commented on GitHub (Apr 28, 2025): I am not particularly experienced with OAuth, so this issue may be specific to that context. However, I would like to highlight two points: 1. Vodafone, atleast as of a few years ago when I tried, was relatively lenient in providing IPv4 addresses to customers at no additional cost. It may be worth a try to contact Vodafone directly and ask about obtaining an IPv4 address. If that approach is unsuccessful (I am looking at you, Deutsche Glasfaser), another option is to purchase an inexpensive VPS—for instance, Ionos offers them for approximately 1€/month. You could then use a VPN solution such as WireGuard to route your traffic through the VPS and obtain IPv4 connectivity. Addressing the root cause: a domain will generally attempt to resolve to an IPv4 address if an A record is configured. If your connection is DS-Lite only, there is little reason to set an A record in your DNS configuration. By omitting the A record, clients will be forced to resolve the domain via IPv6.
adam commented 2026-04-25 00:09:57 +02:00
Author
Owner
Copy Link
Copy Source

@Sapd commented on GitHub (May 16, 2025):

I noticed in the logs, that the URL is translated into an IPv4 address. So i asume any request is directed to an IPv4 address which isnt accessable, instead of an URL which can be resolved.

I do not think it is an ABS issue.

ABS itself does not save an IP. It really just saves the IssuerURL and then connects to it over a library dynamically (and the library also does not cache an IP).

What I suspect is that your docker container might not have ipv6 connectivity or something else in your stack.

@Sapd commented on GitHub (May 16, 2025): > I noticed in the logs, that the URL is translated into an IPv4 address. So i asume any request is directed to an IPv4 address which isnt accessable, instead of an URL which can be resolved. I do not think it is an ABS issue. ABS itself does not save an IP. It really just saves the IssuerURL and then connects to it over a library dynamically (and the library also does not cache an IP). What I suspect is that your docker container might not have ipv6 connectivity or something else in your stack.
adam commented 2026-04-25 00:09:58 +02:00
Author
Owner
Copy Link
Copy Source

@DaAndaDepp commented on GitHub (May 18, 2025):

thanks sugesting this, will check it out, when i got some time

@DaAndaDepp commented on GitHub (May 18, 2025): thanks sugesting this, will check it out, when i got some time
Sign in to join this conversation.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels
authentication
backlog
bug
chapter editor
config-issue
ebooks
encoding/embedding
enhancement
help wanted
listening sessions & progress
planned
possible plugin
progress sync
pull-request
Mirrored from GitHub Pull Request
 sorting/filtering/searching
unable to reproduce
upload
users & permissions
waiting
No Label bug
Milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
adam (Adam Melkus)
No Assignees
1 Participants
Notifications
Due Date
No due date set.
Dependencies

No dependencies set.

Reference: starred/audiobookshelf#2725
Delete Branch "%!s()"

Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?