[FEATURE] Whitelist IPs globally

[dougmaitelli]

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

[alexandreblin]

I agree, it could be nice to also have global settings for other labels too, e.g. tinyauth.apps.[app].users.allow and tinyauth.apps.[app].oauth.whitelist so 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]

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]

#160 (comment)

[steveiliop56]

Added in #567. You will be able to use this feature with TINYAUTH_AUTH_IP_ALLOW and TINYAUTH_AUTH_IP_BLOCK. Keep in mind that the IP whitelists will be merged with the app labels.

[dougmaitelli]

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]

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]

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.

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]

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]

@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 with TINYAUTH_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 like tinyauth.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 thought TINYAUTH_AUTH_IP_ALLOW enables this behaviour