-
Notifications
You must be signed in to change notification settings - Fork 248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Secret creation non public? #105
Comments
IMO you'd still have the same legal issues even when authentication is applied. I don't see how authentication is related to the subject. |
With authentication you can limit creation of new secrets to those who are authorized (duh!) |
ok, now I see your point. |
On our case we solved this with a reverse proxy (I think that's reccommended in any case) enforcing authentication for the base path '/' while allowing unauthenticated access to /snappass.* (secret reveal) and /static/* (resources such as js, css) paths. |
That sounds like a good solution, perhaps a configuration like that could be added to the documentation. |
Is it possible to somehow restrict the creation of secrets for example by basic authentication?
The secret links should still function directly without authentication.
I'm a little bit sceptic on providing the full functionality (including creation of new secrets) as a free unlimited public service. Since I can't control what people share with it, there might be legal issues that I would prefer to avoid.
The text was updated successfully, but these errors were encountered: