-
Notifications
You must be signed in to change notification settings - Fork 48
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
Configurable endpoint for the magic link ? #10
Comments
Interesting idea. The endpoint is already random from the time the first magic link is created. You can also change the endpoint to a new, random one by running
It sounds like perhaps you are referring to a unique endpoint for each magic login link though? |
I was referring that instead of http://www.example.com/6c7de716/382c80-ce6a4188-e9c88e8855 (which is made up of SITE_URL/random/random/) we could have SITE_URL/variable-that-i-can-change/random/ :) |
Would |
I think something like the env var passed before running the command, as you commented on #9 would be most useful. For example, in order to further secure the login, the webserver administrator could configure the prefixed URLs to require specific user agent strings, or a valid SSL client certificate, or restrict to office hours (or out of them). This way, in order to avoid having to quote with backticks the login links as commented in #1, the webserver would not pass the request to WP if it doesn't appear to be comming from a real user, and instead is coming from the app trying to preload the link. |
This would also be useful if Kinsta was the host with Remove Set-Cookie Headers feature enabled since we need a known prefix to let the request passthrough without caching (Cache-Control etc not supported at Kinsta). Edit: I just checked the code and noticed wp-cli-login-server supports arbitrary prefixed paths :) So just need a filter for the magic url shown/emailed |
I think it would be great to have the means to change the way the links work. I.E: Having a link under a random (obviously user configurable) location and things like that would strengthen the plugin's security.
The text was updated successfully, but these errors were encountered: