[Enhancement]: User access control based on subnet #826

New issue

Open

opened 2026-02-20 01:10:57 -05:00 by deekerman · 3 comments

deekerman commented

2026-02-20 01:10:57 -05:00

Owner

Originally created by @cassieesposito on GitHub (Dec 14, 2022).

Describe the feature/enhancement

Allow/deny access to particular users based on the IP/subnet they're connecting from.

There are several use cases for this:

Deny access to admin account from external IPs
Deny access from mobile data IP ranges so as to prevent "oopsie" moments
Integrates with other schedule based access controls that are accomplished by making certain wi-fi networks available or not at certain times of day
Probably others. These are just the ones I thought of. Specifically the first one, because I've finally gotten around to making my ABS instance available to me via Internet.

Originally created by @cassieesposito on GitHub (Dec 14, 2022). ### Describe the feature/enhancement Allow/deny access to particular users based on the IP/subnet they're connecting from. There are several use cases for this: - Deny access to admin account from external IPs - Deny access from mobile data IP ranges so as to prevent "oopsie" moments - Integrates with other schedule based access controls that are accomplished by making certain wi-fi networks available or not at certain times of day - Probably others. These are just the ones I thought of. Specifically the first one, because I've finally gotten around to making my ABS instance available to me via Internet.

deekerman added the

enhancement

backlog

users & permissions

labels

2026-02-20 01:10:57 -05:00

deekerman commented

2026-02-20 01:10:57 -05:00

Author

Owner

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

I think this is something the end-user would configure on their server and out of the scope of Abs. I may be misunderstanding though what you are requesting. Do you have an example project that does this?

@advplyr commented on GitHub (Mar 22, 2023): I think this is something the end-user would configure on their server and out of the scope of Abs. I may be misunderstanding though what you are requesting. Do you have an example project that does this?

deekerman commented

2026-02-20 01:10:58 -05:00

Author

Owner

@cassieesposito commented on GitHub (Mar 23, 2023):

An example of a project that does this is Jellyfin. If you go in to the Networking settings, there is a setting for LAN networks where you can define a comma separated list of IP addresses or subnets. Once you've done that, each user account has a checkbox setting for "Allow remote connections to this server"

I haven't actually looked in to the details of how this is implemented, but the approach that seems obvious to me and will (I hope) more clearly define the behavior I'm describing is as follows.
If LAN networks is defined, upon an authentication attempt, Jellyfin checks whether the user account allows remote connections. If it does not, Jellyfin checks whether the originating IP address is included in Lan networks. If it is not, the authentication request is rejected without ever making a password challenge attempt.

This has at least two use cases, possibly more:

The admin account can be set to disallow remote connections.
- This dramatically improves the security of the system by preventing admin access to ABS, even if the admin password is compromised unless the following additional hoops are jumped through:
  - Finding a bug in ABS that allows escalation from a user privileges to admin privileges OR
  - Compromising the LAN
- This comes at the cost of being unable to access ABS admin functions remotely unless you do it via VPN, SSH tunnel, or another external-to-ABS solution for making traffic originate within the LAN.
Allowing a child whose language skills are subpar to use an insecure password without compromising the security of the user account while still allowing other users to make remote connections.

Configuring this outside of ABS would be a significantly more difficult and fragile process. One possible approach would be to set up an intermediate layer of user authentication at the reverse proxy level. You would have to set the credentials to match the ABS credentials. Upon a successful login attempt to the the intermediate layer, it would forward the credentials to ABS.

To allow users to update their password without breaking the system, you could create a password update option at the intermediate layer. Upon receiving a successful password update request, it would forward the request to ABS. Upon receiving a success message from ABS, it could update its internal password.
- I believe to make this work, you would need to create and maintain apps for both iOS and Android in order to have it work with the respective ABS apps
  - You could probably somewhat reduce this burden using a framework like React Native, but you would still need some platform specific code to deal with the mobile platform's respective security policies that keep apps isolated from each other.
    - I don't honestly know whether this is even possible on iOS -- I know that system takes app isolation EXTREMELY seriously.
    - This has the high potential to break in the event that a mobile platform updates its security policies. I know Android has done this in the relatively recent past, and it's easy for me to imagine they're not done refining that.
This is fragile for the following reasons:
- If a user updates their password through the ABS interface, they would no longer be able to log in without manual intervention from an administrator
- If the password update request to ABS succeeded, but the response to the intermediate layer failed, the user would get an "update failed" message, they would no longer be able to log in without manual intervention from an administrator
- These issues could be somewhat mitigated with a message in response to failed login attempts along the lines of "authentication failed. If you've recently updated your password or attempted to update your password but failed, please enter both the old and new passwords" along with a form for both old and new passwords. Upon receiving a user/oldPW/newPW request, the intermediate layer could try both combinations and if one of them succeeded, make the relevant updates.
  - This is terrible UX
  - This only works if the user still knows both passwords. The chances of this not being the case for users who use password managers is high

In conclusion, this would be dramatically more work than handling this within ABS and would produce a significantly worse product.

@cassieesposito commented on GitHub (Mar 23, 2023): An example of a project that does this is Jellyfin. If you go in to the Networking settings, there is a setting for LAN networks where you can define a comma separated list of IP addresses or subnets. Once you've done that, each user account has a checkbox setting for "Allow remote connections to this server" I haven't actually looked in to the details of how this is implemented, but the approach that seems obvious to me and will (I hope) more clearly define the behavior I'm describing is as follows. If LAN networks is defined, upon an authentication attempt, Jellyfin checks whether the user account allows remote connections. If it does not, Jellyfin checks whether the originating IP address is included in Lan networks. If it is not, the authentication request is rejected without ever making a password challenge attempt. This has at least two use cases, possibly more: 1. The admin account can be set to disallow remote connections. - This dramatically improves the security of the system by preventing admin access to ABS, even if the admin password is compromised unless the following additional hoops are jumped through: - Finding a bug in ABS that allows escalation from a user privileges to admin privileges OR - Compromising the LAN - This comes at the cost of being unable to access ABS admin functions remotely unless you do it via VPN, SSH tunnel, or another external-to-ABS solution for making traffic originate within the LAN. 2. Allowing a child whose language skills are subpar to use an insecure password without compromising the security of the user account while still allowing other users to make remote connections. Configuring this outside of ABS would be a significantly more difficult and fragile process. One possible approach would be to set up an intermediate layer of user authentication at the reverse proxy level. You would have to set the credentials to match the ABS credentials. Upon a successful login attempt to the the intermediate layer, it would forward the credentials to ABS. - To allow users to update their password without breaking the system, you could create a password update option at the intermediate layer. Upon receiving a successful password update request, it would forward the request to ABS. Upon receiving a success message from ABS, it could update its internal password. - I believe to make this work, you would need to create and maintain apps for both iOS and Android in order to have it work with the respective ABS apps - You could probably somewhat reduce this burden using a framework like React Native, but you would still need some platform specific code to deal with the mobile platform's respective security policies that keep apps isolated from each other. - I don't honestly know whether this is even possible on iOS -- I know that system takes app isolation EXTREMELY seriously. - This has the high potential to break in the event that a mobile platform updates its security policies. I know Android has done this in the relatively recent past, and it's easy for me to imagine they're not done refining that. - This is fragile for the following reasons: - If a user updates their password through the ABS interface, they would no longer be able to log in without manual intervention from an administrator - If the password update request to ABS succeeded, but the response to the intermediate layer failed, the user would get an "update failed" message, they would no longer be able to log in without manual intervention from an administrator - These issues could be somewhat mitigated with a message in response to failed login attempts along the lines of "authentication failed. If you've recently updated your password or attempted to update your password but failed, please enter both the old and new passwords" along with a form for both old and new passwords. Upon receiving a user/oldPW/newPW request, the intermediate layer could try both combinations and if one of them succeeded, make the relevant updates. - This is terrible UX - This only works if the user still knows both passwords. The chances of this not being the case for users who use password managers is high In conclusion, this would be dramatically more work than handling this within ABS and would produce a significantly worse product.

deekerman commented

2026-02-20 01:10:58 -05:00

Author

Owner

@advplyr commented on GitHub (Apr 30, 2023):

I still think this would be better suited for the user to setup once we finish implementing passportjs here https://github.com/advplyr/audiobookshelf/pull/1636

I'm not sure though

@advplyr commented on GitHub (Apr 30, 2023): I still think this would be better suited for the user to setup once we finish implementing passportjs here https://github.com/advplyr/audiobookshelf/pull/1636 I'm not sure though