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

Fixed login flow for new tenants, refactored verification email resend #364

Merged
merged 20 commits into from
Jan 16, 2018

Conversation

joshcanhelp
Copy link
Contributor

New tenants were unable to create accounts in WordPress because the login was using the deprecated ID token process (legacy accounts had a setting activated that would allow this). This PR switches the login process to use access_tokens, which works for legacy and new.

This also refactors the resend email process, which was exposing management tokens.

Caveat here: the WP-created client needs to be authorized on the management API before the resend email process will work.

@joshcanhelp joshcanhelp added this to the v3-Next milestone Jan 16, 2018
WP_Auth0.php Outdated
@@ -11,7 +11,7 @@
define( 'WPA0_PLUGIN_URL', trailingslashit( plugin_dir_url( __FILE__ ) ) );
define( 'WPA0_LANG', 'wp-auth0' ); // deprecated; do not use for translations
define( 'AUTH0_DB_VERSION', 15 );
define( 'WPA0_VERSION', '3.4.0' );
define( 'WPA0_VERSION', '3.4.1' );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

If this is the version of this library, then don't bump the version here. Do it in a separate "release pr" instead.

WP_Auth0.php Outdated
@@ -2,7 +2,7 @@
/**
* Plugin Name: PLUGIN_NAME
* Description: PLUGIN_DESCRIPTION
* Version: 3.4.0
* Version: 3.4.1
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

See below

@@ -0,0 +1,30 @@
/* globals jQuery, console, WPAuth0EmailVerification */
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why is it called "die-with-verify-email" ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lbalmaceda - The process dies using wp_die() and only happens if the incoming user needs to verify the email. Baiscally: process stops, nothing proceeds.

$.post( WPAuth0EmailVerification.ajaxUrl, postData )
.done( function( data ) {

if ( '1' === data ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

No magic numbers

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lbalmaceda - Unfortunately WP has a default magic number for AJAX calls ("-1" if you don't pass the nonce check) so a bit of a bad pattern WP folks follow. Will adjust to something more clear.

*
* @return string
*/
public static function get_endpoint( $path = '', $domain = '' ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why does it need to be public?? The signature is too error prone for the end user.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lbalmaceda - Everything is public static in that file, for better or worse. This is a case of consistency vs accuracy :)

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

But if this file is going to end up being the "API Client" then I would prefer not to leave this method open for users to use, as it's only used internally, and also because once we publish this we can't remove it without breaking the public api.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lbalmaceda - I see what you're getting at here. Was a little confused with who you were referring to as "users" but I see the 💡

$msg .= ' '. $e->getMessage();
$msg .= '<br/><br/>';
$msg .= '<a href="' . wp_login_url() . '">' . __( '← Login', 'wp-auth0' ) . '</a>';
wp_die( $msg );

} catch (WP_Auth0_BeforeLoginException $e) {

$msg = __( 'You have logged in successfully, but there is a problem accessing this site', 'wp-auth0' );
$msg = __( 'You have logged in successfully, but there is a problem accessing this site. ', 'wp-auth0' );
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

i18n?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lbalmaceda - yes?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should probably change these back as this will break existing i18n for this message as it's changed.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It's not that the main message changed but fixed grammatically, I see no need to rollback this change.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Well fixing it breaks it for existing use, no huge feeling either way.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We don't have a PO file in here that we keep up to date so if someone is generating that and translating for themselves, they'll be used to doing that on each release (or used to things breaking/not translating).

$response = WP_Auth0_Api_Client::get_user( $domain, $data->id_token, $decodedToken->sub );
}

$data->id_token = null;
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why you remove the id_token but not the access_token?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lbalmaceda - Not sure I'm totally clear on your question but this was basically 'if you have an id token, use it, otherwise use the access token' and we want to get rid of the first condition. I'm forcing it to use the access_token and left the $data->id_token = null; because I don't know what the downstream effects are of keeping that id_token around. Maybe there is another check like this down the line? Seemed safer to leave this than remove it.

* @param $id_token
*/
private function dieWithVerifyEmail( $userinfo, $id_token = '' ) {
trigger_error( __( 'Method dieWithVerifyEmail is deprecated.', 'wp-auth0' ), E_USER_DEPRECATED);
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't fully understand the trigger_error method. Is it just logging an error on the console or exploding over the air? If the latter then this is no deprecation. This is breaking the api 🤕 . Old methods must remain the same, working without changing their signature at all. Normally we achieve this by re-routing the call to the new method that will eventually replace it. On a side note, we prefer to handle deprecations on a separate PR so the changelog is clearer. Would you mind rolling back this change?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lbalmaceda - trigger_error is just that, triggers an error of a certain type. Depending on the error type and the environment, it will be handled different ways. In the case of a deprecated error like this one, it's either displayed or not, won't stop the process from continuing.

Happy to do whatever is prudent here but the idea here is that the function still exists and can be called as based but does the right thing with a soft error. Signature is essentially the same, just defaulting to a blank $id_token and the replacement function is called with the $userinfo it needs. The chances that this function is being used in the wild is very small but, if so, this should keep folks running.

Let me know if you still want me to back it out and how to handle going forward!

* WP_Auth0_EmailNotVerifiedException constructor.
*
* @param stdClass $userinfo - userinfo object returned from Auth0
* @param string $id_token - DEPRECATED 3.4.1, should not be output in any template
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Move to a separate PR please

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lbalmaceda - Will wait for direction on the other one so I can do them both. Should they each be in their own PR?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Not necessary as long as the PR only deprecates stuff 👌

*
* @return null|WP_User
*/
public function find_auth0_user ( $id ) {
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Just asking. Why is this method needed?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@lbalmaceda - Finding the WP user with Auth0 info

@cocojoe
Copy link
Member

cocojoe commented Jan 16, 2018

@joshcanhelp Have you tested on new and old (make sure still works) tenants?

@joshcanhelp
Copy link
Contributor Author

@cocojoe - Yes, walked through start to finish on old and new tenants

Copy link
Member

@cocojoe cocojoe left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Have discussed internally, fine as tested.

@joshcanhelp joshcanhelp merged commit 798a31a into dev Jan 16, 2018
@cocojoe cocojoe deleted the fixed-token-login-flow branch January 18, 2018 09:49
@cocojoe cocojoe mentioned this pull request Jan 25, 2018
@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

Successfully merging this pull request may close these issues.

None yet

3 participants