auth0 / wordpress Goto Github PK

The Login Widget is now shown only in the login page. Some pages/themes have always wanted to show the Login Widget as a WP Widget anywhere in the page (Right sidebar for example) or as a Shortcode.

This error
https://github.com/auth0/wp-auth0/blob/master/WP_Auth0.php#L167

And this error
https://github.com/auth0/wp-auth0/blob/master/WP_Auth0.php#L179

Are only accesible by looking at the apache log and sometimes that's not available. Show those errors as part of the error page.

https://github.com/auth0/lock/wiki/Migration-Guide

right now it fails with the an empty message
we should show
"Please check your Client Secret on the settings plugin is the same as the one on the Auth0 dashboard"

Problems like https://ask.auth0.com/t/problems-with-callback-url/120

Let's add an option to enter a custom CSS. That way users will be able to use Themes.

http://auth0-wp.azurewebsites.net/

returns a 403

The lock should be able to function with a redirect without needing the client secret at all.

We should let the user be able to set the widget options when calling in the signin configurable in the Settings page on the WP plugin

Entering invalid settings such as a mistyped client ID, secret or tenant can cripple a Wordpress installation, since it breaks the login. These settings should be validated before saving to ensure the login configuration is always in a valid state.

Given the "Single Sign On (SSO)" is checked in the Auth0 settings and "Auto Login (no widget)" is unchecked.

To reproduce this issue:

1. Login via wordpress auth0 widget.
2. Logout (it only logs out of Wordpress not Auth0).
3. Go to http://[domain.com]/wp-login.php

The application now results in error:
Type: Failed Login
Description: http://[domain.com]/wp-login.php is not in the list of authorized callback URLs: http://[domain.com]/index.php?auth0=1. Please go to 'https://manage.auth0.com/#/applications/raFDFlsRPwMTbHT6Jyg7ZARG4QJVvkz6/settings' and make sure you are sending the same callback url from your application.
Connection: Username-Password-Authentication

It's probably because require verification is not checked on WP

Currently it seems like Auth0 calculates the WPA0_PLUGIN_URL too soon in the process, so the URL of the CSS files doesn't get https:// on a secure site.

Calculating this value on demand fixes the problem, e.g.:

    wp_enqueue_style( 'auth0-widget', trailingslashit(plugin_dir_url(__FILE__) ) . 'assets/css/main.css' );

If SSO is enabled, it should redirect to /authorize (only if there is SSO cookie).
On logout should single logout

In the file https://github.com/auth0/wp-auth0/blob/master/templates/auth0-login-form.php#L122 there is hardwired place of wordpress index.php.
Our issue is, that we have wordpress in the subdirectory of the webserver, to be precise on /articles/ , so we need the path /articles/index.php there. Maybe the best solution will be to prefix index.php by wordpress site url <?php echo get_site_url(); ?>.

The related support issue on wordpress.org is https://wordpress.org/support/topic/hardwired-redirect-url-after-login

The shortcode attributes are being ignored. In this example, the Lock's title will never be changed, even tough the form_title attributed is defined on the shortcode.

[auth0 show_as_modal="true" social_big_buttons="true" form_title="Please login on my WP blog"]

Reported here: https://ask.auth0.com/t/shortcode-attributes-go-nowhere-in-auth0-plugin/464

We should add a Link to Create Auth0 Account next to the clientId and clientSecret.

In order to use thisplugin, you need to first create an application on Auth0 and copy the information here

Even though I am using the following settings:

'auto_login' => 0,
'auto_login_method' => '',

When I try to login from the wp-login.php page the connection field is being set to just one value so that login is failing because not all of the connections are being considered.

( ! ) Warning: session_start(): The session id is too long or contains illegal characters, valid characters are a-z, A-Z, 0-9 and '-,' in /home/thanh/dev/site/local_dev_wp/wp-content/plugins/auth0/WP_Auth0.php on line 569

( ! ) Warning: session_start(): Cannot send session cache limiter - headers already sent (output started at /home/thanh/dev/site/local_dev_wp/wp-content/plugins/auth0/WP_Auth0.php:569) in /home/thanh/dev/site/local_dev_wp/wp-content/plugins/auth0/WP_Auth0.php on line 569

Currently, the plugin redirects to either the main blog, the original page that was requested before logging in, or the admin panel. This should be configurable with an arbitrary relative or absolute URL.

https://auth0.com/docs/hrd#3

For security reasons, the field "Client Secret" should be marked such that the browser auto complete does not save the value.

@woloski and @rolodato have both updated to the latest version of the Plugin and the Widget is not shown anymore. It's not that it's hidden it just isn't in the HTML.

The "disable WordPress login" option should only be cosmetic, and a fallback URL should be provided to always be able to log in with WordPress credentials. As an example, Zendesk does this when enabling SSO by sending a fallback URL by email to prevent locking oneself out from their account.

Manually deleting stuff through FTP or SSH is not fun :)

The wp-login?wle page does not work when the "Auto Login (no widget)" option is enabled and points to a specific connection (like google-oauth2). Instead of redirecting to Auth0 it should show the Wordpress login page

With the recent commit, the error triggered by username collisions is no longer suppressed, but this means that users different accounts with the same username will receive an error message telling them that their username already exists.

The issue arises because Auth0 usernames are simply the first part of the email address, up to the @ symbol. But, several users can have the same username, since Auth0 only requires the full email to be unique.

Would it be possible to switch from using Auth0 usernames (which are not unique) to Auth0 email addresses (which are) for the WP username?

I was having issues where the menu page would not be linked inside of the admin navigation. In particular I found this issue was happening when ACF Pro was activated http://www.advancedcustomfields.com/ I tried to track down where the conflict was happening and found that if I prevented ACF from generating it's menu page the auth0 menu page link appeared.

Considering that ACF is one of the most popular plugins for wordpress I thought it would reasonable that both plugins should work together.

When comparing the method that each plugin creates it's admin page, I found that both plugins were in fact using the correct action "admin-menu" to hook into, but ACF has set it's priority and accepted arguments whereas wp-auth0 used the defaults.

Here is ACF's action

add_action('admin_menu', array($this,'admin_menu'), 99, 0);

And now wp-auth0's

add_action( 'admin_menu', array(__CLASS__, 'init_menu') );

If I add a priority to wp-auth0 of 99+ the conflict resolves itself. Or if I remove the priority argument from ACF the conflict resolves itself. I am not positive what is best practice here, to use the defaults or set a custom priority. I will post a duplicate issue one the ACF plugin github, so that hopefully these types of conflicts can be avoided.

I am getting the following error after I login:

Error: Could not create user. The registration process is not available.

This seems to be caused by this: https://github.com/auth0/wp-auth0/blob/fed6a4916de0e74d365653f3a6e4a6cb0e78c6d6/lib/WP_Auth0_Options.php#L9 which means that you need to turn on WP user creation to have newly visiting Auth0 users work. This seems wrong.

When using a plugin like "Authenticator" we can lock down a Wordpress site (all content needs authentication). Now in that case the Logout does not work as expected. It will clear the Wordpress cookie but it does not logout from Auth0 or the IdP. As a result the following happens:

1. Logout (clear WP cookie)
2. Go to homepage. Not authenticated
3. Go to Auth0. Auth cookie present, we have SSO
4. Back to WP, user is authenticated.

Note: this only happens when "Auto Login (no widget)" is enabled and a connection is specified (like "google-oauth2")

new approach to pr #56

I have two sites: www.site.com and shop.site.com. I am using Wordpress on the shopping site (specifically WooCommerce). I currently use Auth0 to authenticate on the main site. I have added the Auth0 WP plugin on the shopping site.

I would like to require users to use the same account on both sites. Further I would like to avoid even having the user enter his email/password again on the shopping site if he is directed there from the main site. Is there a way that when I link the user from the main site to the shopping site I can do so along with the jwt which can then be used by the auth0 plugin on the WP site to login the user?

Something like shop.site.com/login?jwt=XXXXXXX?

Ideally the stripe id for the customer would be storable / loadable by Auth0 plugin such that WooCommerce + one of the Stripe plugins could use the token for loading saved payment information.

Per the Stripe docs:

Once you've created a customer, you should store its id in your own database so you can refer to it later when communicating with stripe.

and more here

Stripe plugins for WooCommerce:

• https://wordpress.org/plugins/stripe-for-woocommerce/
• http://www.sellxed.com/shop/en/wordpress-woocommerce-stripe-zahlungs-plugin.html
• http://www.woothemes.com/products/stripe/
• https://wordpress.org/plugins/striper/

There are even more for WordPress in general.

the login page is showing lost your password, it shouldn't

$state = $wp_query->query_vars['state'];
...
if ($stateFromGet->interim) {

Lines 344 & 392

This assumes state is present, and assumes that it's a json_encoded object that always has an interim property. Due to this it throws PHP notices which if displayed prevent auth0 from redirecting.

State isn't always present, like when doing sso via /authorize.

Just use isset checks and it'll fix the problem :)

Thanks

When enabling the option "Auto Login (no widget)" in the plugin settings it's no longer possible to use the Wordpress login. Even when the option "Enable Wordpress login" is set and the user navigates to http://blog/wp-login.php?wle

A prospective customer with an internal wordpress site with no internet access asked what deployment options of Auth0 they could use. Would be nice if the wordpress plugin allowed them to use cloud-based Auth0 by not requiring internet access from the plugin to Auth0, e.g. by routing all traffic through redirects through user browser. (It sounds like today, the direct connection from plugin to Auth0 is required to get a token after authentication, so perhaps this could be done by implementing an option to use token flow instead of code flow).

https://ask.auth0.com/t/wordpress-anyone-can-register-and-allow-signup/793

WordPress requires all users to have both username and email, as can be seen here:

When logging in with an identity provider that does not provide an email such as Instagram or Twitter, user creation fails with Error: could not create user.

A solution for this would be to prompt users for an email when signing up if the identity provider hasn't provided one.

We have enabled auto-redirect for our installation (i.e. going to /admin will not request login credentials just send us round to WAAD for authentication).

Is it possible to intercept requests to preview a post and automatically log in? At the moment I just hit the homepage and a 404 request. Hitting http://blog.timestamphq.com/?p=4581&preview=true when not logged in ends up at http://blog.timestamphq.com/?p=4581 and a 404 page.

I selected "Auto Login (no widget)" but the "My Account" page on WooCommerce shows:

and I am unable to use an email/password here that works with the select Auth0 connection.

related: https://ask.auth0.com/t/auth0-plugin-for-wp-not-fully-replacing-normal-login/794

It would be great if Auth0 could be used to load / store the information needed by the user when checking out in WooCommerce.

This should exclude payment information (CC#s) since that should be stored by the payment gateway.