Passwordless login and state

[Floppy]

Description

When using passwordless login, we're having problems with state in the OAuth flow. Our passwordless flow isn't instant, for various business reasons, and when a users gets the passwordless link to log in, it's entirely possible it might be a few days later.

Problem is that while we can set an auth0_state cookie when they request the passwordless link, I'm really not confident that they'll be using the same browser or even the same machine by the time they get the link, so Wordpress login would fail with Invalid State.

Ideally I don't want a state validation in my passwordless flow, but the plugin requires state validation, understandably. I'm not sure what to do. Ideally I'd be able to disable state validation, but I know that's been rejected before.

Prerequisites

• Have you read Auth0's general contribution guidelines?
• Have you read Auth0's code of conduct guidelines
• Did you check the documentation?
• Did you check the Auth0 Community?
• Did you check the WP.org Support Forum?
• Are there any related or duplicate Issues or PRs in this repo?

Environment

• WP-Auth0 version: 3.8.0
• WordPress version: 4.9.2

Reproduction

Request a magic link with a mismatched (or missing) state parameter & auth0_cookie.

[joshcanhelp]

@Floppy - What you're describing here is, more-or-less, what state validation is meant to prevent: a different machine trying to log in that did not initiate the process.

If you're having problems with the link, try the emailed code instead (remove {"passwordlessMethod":"link"} from the Extra Settings field). You can adjust the expiration of that code in the Auth0 dashboard:

Auth0 Dashboard > Connections > Passwordless > Email > Settings > OTP Expiry

I'm not sure you want that set to several days, though, and I'm curious how your users are waiting that long to log in. If that's really the case, wouldn't a more direct login flow be better suited for what you're doing?

[Floppy]

Yeah, I understand that this is precisely what state is for, and is working as intended. Our use case is definitely odd, here. I've got a workaround for now; I'll think on this some more and reopen if appropriate.