Status page without password

is it possible to have the “status” page accessible without a password (read only and without setup/tools menus) for the local network?
I would like to display this page permanently on an old android tablet without having to enter the password every day :slight_smile:

You are asking if the password can be required only when the request is from the WAN? That sounds like a useful feature. I’ll take a look at that.

yes i think ^^
when requests come from the gateway, logically they come from the WAN (NAT).
But with WiFi I’m not sure, because at home the gateway is also a WiFi router…

Maybe the way to think about it is to consider any request from the gatewayIP to be from the outside world, and any other request from the LAN. I can do that with the information available.

Now without overthinking this and adding a lot of complicated options, maybe a checkbox on the password setup to say no password required on the local LAN.

I realize your request wants to continue to restrict the non password local LAN user to a subset of activities, but that gets very messy. Would it usefil to have a mechanism to simply say passwords only apply for sessions originating from the gateway?

I have coded that up, it seems to work fine for me with local devices getting carte-blanche while a port-forwarded session is subject to password authentication.

it would be perfect not to enter the password at all locally :slight_smile:
The checkbox idea is perfect.
Don’t worry about the restriction of functions, it was a security suggestion (password to access the admin part only), not an obligation for me ;o)

1 Like

in which version do you plan to make this feature available to everyone?

The changes are complete. It will go out in the next release, probably ALPHA in a few weeks if all goes well.

Incidentally, as part of working on this I revisited the authorization mechanism and discovered why it often requires logging in multiple times. It all related to a quirk in several browsers where they send multiple requests out of sequence. I have designed a workaround for that and the new version now works solid after the password is entered.