Repository navigation
[FEATURE] Whitelist IPs globally #516
Description
Is your feature request related to a problem? Please describe.
Its my understanding that it is possible to skip auth for specific IP ranges but this has to be done by app.
Describe the solution you'd like
It would be good if this could be defined globally to skip auth for all apps for given IPs
Describe alternatives you've considered
N/A
Additional context
N/A
Activity
alexandreblin commentedon Dec 16, 2025
I agree, it could be nice to also have global settings for other labels too, e.g.
tinyauth.apps.[app].users.allowandtinyauth.apps.[app].oauth.whitelistso by default all apps are restricted to a user (me) and be able to override it per-app to add friends/family.This way the default setting is safe, any new app will not be opened to everyone by default
ilkersigirci commentedon Dec 17, 2025
This feature is very needed IMHO. For example, it would be perfect fit for people using tailscale etc, to bypass its CIDR and use authentication for all other IP ranges.
OneCreek commentedon Dec 18, 2025
#160 (comment)
steveiliop56 commentedon Jan 8, 2026
Added in #567. You will be able to use this feature with
TINYAUTH_AUTH_IP_ALLOWandTINYAUTH_AUTH_IP_BLOCK. Keep in mind that the IP whitelists will be merged with the app labels.dougmaitelli commentedon Jan 14, 2026
Hey @steveiliop56, thanks for adding this!
Do you know when a new release will be made including this feature?
EDIT: Just saw the milestone on the right side :)
steveiliop56 commentedon Jan 15, 2026
Well milestone is a bit wrong, I would add 2-3 weeks to that because I still haven't implemented OIDC + all the testing that's needed for v5.
OneCreek commentedon Jan 22, 2026
Have you thought about releasing it separately? There are quite a few nice fixes/add-ons that are already ready.
I understand it's always nice to have many new things for a new major, but why not starting to count faster like Firefox or Chrome:)
Is there any big risk in using a nightly for testing? Or how about a beta in-between before the milestone v5:)
steveiliop56 commentedon Jan 22, 2026
You are right, I can indeed release v5 alone but I would like to add the OIDC as a "reward" for the amount of time that you will need to spend to migrate to the new version. Nevertheless if I don't have OIDC ready in 2 weeks time (and to a level that I believe is usable and acceptable for an OIDC implementation), I will skip it.
As for the nightly, it comes with the risks that every nightly release may have. It's unstable as in configuration may change from release to release. I wouldn't use it for anything other than testing (obviously) but if you are willing to test out the new changes, it should work.
Feel free to provide any feedback in a discussion or in the discord server. I also believe it would be a good idea to release an alpha so as people can test and I can fix issues while working on OIDC.
ilkersigirci commentedon Mar 7, 2026
@steveiliop56 I have just tried the
v5. First off, another awesome work. Thanks for that. But it seems that globally IP bypass isn't working in my end. I have deployed tinyauth withTINYAUTH_AUTH_IP_ALLOW: 127.0.0.1/32,10.8.0.0/24,192.168.0.0/16,172.16.0.0/12. I don't have any app level config liketinyauth.apps.APPNAME.config.domain,tinyauth.apps.APPNAME.ip.bypass. I still see tinyauth login screen in my app. Note that when I set tinyauth app level configs, tinyauth login doesn't show, which is the expected outcome for v4 one. However, I don't want to set this tinyauth labels for each app in my docker compose stack. I thoughtTINYAUTH_AUTH_IP_ALLOWenables this behavioursteveiliop56 commentedon Mar 7, 2026
@ilkersigirci I decided to omit the bypass option and only keep allow and block. It seemed way to dangerous to me to be able to disable authentication for a whole network with one option. I believe the best way going forward is to do it on a per-app basis with ACLs.
ilkersigirci commentedon Mar 7, 2026
I got your point. However, I just think giving the user the option would be the better choice since it is not a default behavior rather users custom security configuration. And the user is responsible for his/her own decision. Anyway, thanks for the awesome work again. I love your project. I just want to share my thoughts
dougmaitelli commentedon Mar 8, 2026
I agree, bypass would be useful. I don't want authentication to happen between containers, the bypass is a way to let them talk to each other inside the same closed network without needing auth.
steveiliop56 commentedon Mar 8, 2026
Alright, I will reopen this issue and revisit it in the next feature release of Tinyauth.
unethical-forest commentedon May 3, 2026
In similar nature as well, for something such as a health checking application like Uptime Kuma.
ilkersigirci commentedon May 20, 2026
Could you please tell us what the current progress is for this @steveiliop56?
steveiliop56 commentedon May 20, 2026
@ilkersigirci it's in my backlog right now. Should be an easy feature to add. I would like to first finish with some other things I am working on and I will pick it up. Hopefully we can have it ready for v5.1.