Refactor authentication to prevent conflicts with plugins that determine the current user too early. #97
Conversation
…rly. See #94 This seeks to work around conflicts with plugins that determine the current user during plugins_loaded by wiring up the determine_current_user filter immediately, so that authentication can be handled whenever wp_get_current_user() is called. Authentication servers have been refactored to simplify the interface and move state management and type gymnastics into the Authentication provider.
src/Authentication/ApiKey/Server.php
Outdated
| header( 'WWW-Authenticate: Basic realm="SatisPress"' ); | ||
| } | ||
|
|
||
| $status_code = empty( $error_data['status'] ) ? HTTP::INTERNAL_SERVER_ERROR : $error_data['status']; | ||
| wp_die( wp_kses_data( $error->get_error_message() ), absint( $status_code ) ); | ||
| wp_die( wp_kses_data( $e->getMessage() ), absint( $e->getStatusCode() ) ); |
There was a problem hiding this comment.
Is there a way to let another class handle this sanitization and dieing, so that there is no need to link this class to WP code?
(There's an is_wp_error() further down as well).
I guess what I'm thinking of, is some sort of ErrorHandler interface, of which there could be a WPErrorHandler implementation that would actually do the wp_die(), that multiple classes could use.
Or moving this into an Exception class.
There was a problem hiding this comment.
I've been thinking on this and can't really come up with a solution that isn't convoluted. The authentication handling was designed to be compatible with the REST API in case REST routes are registered in the future. The current wp_die() approach isn't really compatible with that, but neither is throwing an exception since authentication errors are retrieved through the rest_authentication_errors filter, which expects WP_Error, null, or true. It's also not possible to send headers through WP_Error.
Hmm, maybe the headers can be added when the HttpException is created in the authenticate() method. Then the handle_error() method can be dropped. Authentication::get_authentication_errors() can then convert the exception into an error object for REST requests, or rethrow the exception for the request handler to convert it into a response.
There was a problem hiding this comment.
@GaryJones Let me know what you think of those changes. I'm not sure if the authentication exceptions are doing too much or not. This does simplify the logic in the servers quite a bit, though.
This creates a new AuthenticationException exception to transport authentication errors, including headers and status code, from the authenticate() method instead of using a handle_error() method. If the current request is a REST request, the Authentication provider will convert the exception to an error instead of allowing the exception to bubble up.
bradyvercher
force-pushed
the
refactor-auth
branch
from
497eafa
to
9168411
Compare
This seeks to work around conflicts with plugins that determine the current user during
plugins_loadedby wiring up thedetermine_current_userfilter immediately, so that authentication can be handled wheneverwp_get_current_user()is called. See #94Authentication servers have been refactored to simplify the interface and move state management and type gymnastics into the Authentication provider.