Skip to content
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

Open
niladam opened this issue Jan 14, 2017 · 5 comments
Open

Configurable endpoint for the magic link ? #10

niladam opened this issue Jan 14, 2017 · 5 comments

Comments

@niladam
Copy link

niladam commented Jan 14, 2017

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.

@aaemnnosttv
Copy link
Owner

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

wp login invalidate

It sounds like perhaps you are referring to a unique endpoint for each magic login link though?

@niladam
Copy link
Author

niladam commented Jan 14, 2017

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/ :)

@aaemnnosttv
Copy link
Owner

Would variable-that-i-can-change be for all magic links or something you want to be able to set on a per-link basis?

@tzkmx
Copy link

tzkmx commented Mar 28, 2017

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.

@oxyc
Copy link

oxyc commented Jul 31, 2024

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

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

4 participants