You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
In certain scenarios it could be useful to don't have a password, for example when you're not exposing the docker container to the network (even private network), but only to localhost. That's the only reasonable scenario when it could be okay to don't have a password-protected instance (even in private networks it's a problem).
Something like this could be implemented:
Option 1
On first install generates a random uuid and use that as a one-time use path for a setting password page. e.g. http://localhost:8000/3da194fb-8363-48c2-a210-9f3eafc10533.
How to provide to the user this URL? I don't know, printing the URL in the terminal could be a problem (if they use -d in docker-compose up).
The page presents the option to set a password or to don't use a password (with a banner saying "You have to know you are doing a stupid thing").
Once the decision is made, the URL becomes invalid and that page is not accessible anymore. The password options are then only editable in the settings.
I know security by obscurity is not something useful, but in my opinion a uuid v4 for this scenario could be okay.
I know you provide an hosted version of changedetection too, so I don't know if this is a problematic process and how this can be adapted to the hosted version.
Option 2
Another option could be to create a file with a temporary pseudo-random password. That one is valid just for the first use, when you login you're prompted with a page giving the user 2 options:
change the password
don't use a password (with the same banner saying "You have to know you are doing a stupid thing")
Finally that file is deleted and the one-time password invalidated.
The text was updated successfully, but these errors were encountered:
In certain scenarios it could be useful to don't have a password, for example when you're not exposing the docker container to the network (even private network), but only to localhost. That's the only reasonable scenario when it could be okay to don't have a password-protected instance (even in private networks it's a problem).
Something like this could be implemented:
Option 1
http://localhost:8000/3da194fb-8363-48c2-a210-9f3eafc10533
.-d
in docker-compose up).I know security by obscurity is not something useful, but in my opinion a uuid v4 for this scenario could be okay.
I know you provide an hosted version of changedetection too, so I don't know if this is a problematic process and how this can be adapted to the hosted version.
Option 2
Another option could be to create a file with a temporary pseudo-random password. That one is valid just for the first use, when you login you're prompted with a page giving the user 2 options:
Finally that file is deleted and the one-time password invalidated.
The text was updated successfully, but these errors were encountered: