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

Handling errors #403

Closed
Floppy opened this issue Feb 20, 2018 · 4 comments
Closed

Handling errors #403

Floppy opened this issue Feb 20, 2018 · 4 comments
Assignees
Milestone

Comments

@Floppy
Copy link

Floppy commented Feb 20, 2018

Our wordpress instance is on Pagely, which irritatingly masks loads of error pages with its own error page, throwing away all the content. When we get OAuth errors, it doesn't show anything useful. Is there any way to tell the plugin to show a specific error page, so that we can customise it?

@joshcanhelp joshcanhelp self-assigned this Feb 20, 2018
@joshcanhelp
Copy link
Contributor

@Floppy - That's not helpful, though I do have it on my list to handle those stop-points better. The function we use, wp_die(), accepts an error response code as an argument so we're able to do do the same thing but send a 200 code instead indicating a success in terms of the page loading instead of an error.

If you would, can you check in with Pagely and see if this would work to skip their error pages?

$msg = __( 'There was a problem with your login', 'wp-auth0' );
$title = __( 'Auth0 error', 'wp-auth0' );
wp_die( $msg, $title, array( 'response' => 200 ) );

@joshcanhelp joshcanhelp added this to the v3-Next milestone Feb 20, 2018
@Floppy
Copy link
Author

Floppy commented Feb 20, 2018

It's very good of you to offer, but thinking about it a bit more, sending a 200 code with an error is a really non-webby thing to do and you shouldn't let me push you into it. I'm sure that sending a 200 would avoid their error trapping, but to me it's not the right thing to do (I'm a bit obsessive about HTTP codes).

We're going to move off there soon anyway, so I think we'll just have to live with it until then.

The thing I was thinking is to perhaps add an error URL option, which could send the error message in GET parameters to a page that could display them. However, I notice while debugging something else that in many cases, a message parameter is passed to the default post-login URL anyway, so it already does what I was thinking of (at least sometimes).

@Floppy Floppy closed this as completed Feb 20, 2018
@joshcanhelp
Copy link
Contributor

I agree that a 200 code with a server error is not a great idea but this isn't a server error that indicates a network problem, it's a problem with a specific user's login process. The server connected, processed the request, and found an issue. I don't think indicating that with a 500 code is the right thing to do. We used wp_die() which just happens to have a response code of 500.

We're working on the next major version of this plugin in the background and improved error handling is high on the list.

Thanks!

@Floppy
Copy link
Author

Floppy commented Feb 26, 2018

Yes, that's true, should be something in the 4xx range probably.

@github-actions github-actions bot locked as resolved and limited conversation to collaborators Sep 19, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants