Forum Replies Created

Viewing 13 replies - 1 through 13 (of 13 total)
  • Thread Starter matthneedh

    (@matthneedh)

    This was deployed 5 days ago, and appears to have resolved all our problems. Thanks for your help!

    Thread Starter matthneedh

    (@matthneedh)

    Clearing the server cache resolved the openssl warning. I’m not expecting any further problems, but I’ll report back when this is live and resolved.

    Thread Starter matthneedh

    (@matthneedh)

    I’ve gotten Universql Login and Custom domain working correctly together, so I’ve not followed up on the exact problem here. As far as I’m concerned, this issue can be closed.

    FWIW, I did determine that the problem for the Windows Chrome user was due to third-party cookies being disabled (even though it shouldn’t have mattered).

    Thanks for your help,

    Matthew

    Thread Starter matthneedh

    (@matthneedh)

    My client has opted to have me a line of code to make “register” not redirect (similar to the redirect for “wle”), while they come up with a long-term fix to not use WP as the required registration point.

    Here’s what I added:

    			// Do not redirect registration.
    			|| ( $_SERVER['REQUEST_URI'] ) == '/register/'

    Everything looks great in my Dev environment, but as soon as I upgraded the Auth0 plugin from 2.6.2 to 2.7.0 in their Dev, I saw the following message at the top of every WP page (even when not logged in):

    Warning: openssl_verify(): supplied key param cannot be coerced into a public key in /srv/bindings/b8971219fa5a47abae990b17a37557bd/code/wp-content/plugins/auth0/lib/php-jwt/Authentication/JWT.php on line 186

    Despite this, everything appear to be working correctly. Googling that string with “Auth0” doesn’t give me any hits for a clue. Any idea what it’s about?

    Thanks,

    Matthew

    • This reply was modified 7 years, 8 months ago by matthneedh.
    Thread Starter matthneedh

    (@matthneedh)

    I added https://cdn.auth0.com.

    I’ve read that topic a few times, but hadn’t really considered using suggestions there since this system is using a Custom Domain.

    What cookies should the user remove? This is the first time the user has attempted to login at this specific domain, though the old authentication domain and the new custom domain *are* the same used for other systems to which the user has attempted to login. I’d rather not ask users to delete all cookies.

    Thread Starter matthneedh

    (@matthneedh)

    I checked with a Windows Chrome user who has historically been seeing the invalid state error (most problems were Safari users with the “unable to configure” failure). Fortunately, he’s no longer seeing the invalid state error. Unfortunately, he’s now seeing the “Unable to configure” error that had previously been limited to Safari.

    After what appear to be a successful login, the lock widget disappears and the user sees a white page that says:

    There was a problem with your log in: Unable to configure verification page.
    [error code: server_error]

    ← Login

    The Login link goes to /login/?skip_sso .

    Thread Starter matthneedh

    (@matthneedh)

    Firefox and Chrome worked, Safari failed. I ended up resolving the Safari problem by adding configurationBaseUrl to the plugin’s Extra Settings.

    Thread Starter matthneedh

    (@matthneedh)

    In a dev environment, I’ve created a plugin with the filter and added the custom domain in the Auth0 plugin (v 2.7.0) interface. I have debug mode enabled without seeing any problems reported.

    The invalid state error is gone, but I’m back to seeing the Safari login error that prompted me to start looking at custom domain: “Failed cross origin authentication: Unable to configure verification page”. Nothing is reported in the plugin error logs. The Auth0 dashboard errors look pretty much identical, except that the “hostname” for the dev login is the custom domain.

    Any ideas where I should go from here?

    Thread Starter matthneedh

    (@matthneedh)

    Sorry. I don’t have a good understanding of exactly how it works, as it was a consultant that set up the site registration last year. Regardless, I am certain that the registration process results in a user account being created in Auth0, and that those Auth0 credentials can then be used by the user to login to oahter services linked to Auth0.

    We do eventually want to move the userdata collection and Salesforce sync functionality from WordPress to Auth0, but that’s not where we are today.

    Thread Starter matthneedh

    (@matthneedh)

    Sorry I wasn’t more explicit. It was working in Chrome and Firefox with v 3.6.2, and then wasn’t after I upgraded to 3.7.0 and added the custom domain. I’ll try the filter, thanks.

    Thread Starter matthneedh

    (@matthneedh)

    I forgot to mention that the Auth0 dashboard logs the login attempt with “Success cross origin authentication”, but no other log types. I can no longer log in to WP to check the log there, so I’m not sure if that provides more info.

    Thread Starter matthneedh

    (@matthneedh)

    The main problem I’m seeing right now is that the custom registration page, located at mysite.com/register/, is being redirected to universal login. At this point, I need WP log in to use Universal Login, but not registration. How do I avoid the redirection of my registration page?

    Thread Starter matthneedh

    (@matthneedh)

    I have two dev environments, one using Universal Login (via the auto login checkbox) and one using the embedded lock. I updated the plugin in each from 3.6.2 to 3.7.0.

    The one with Universal Login works great. The one using the embedded lock widget is no longer allowing me to login, returning the invalid state error (Safari, Chrome, and Firefox). I’ve read https://github.com/joshcanhelp/troubleshooting-invalid-state-wp/, and these sites ARE hosted on Pantheon.

    Given what I described, does it make sense that the universal login would work, but the embedded login would not? Would it make sense for the embedded login to stop working on Chrome and Firefox, when it had previously only been failing on Safari?

    I’m guessing I’ll need to make tweaks due to Pantheon hosting, but it isn’t clear to me exactly what changes are needed.

    Thanks for your help.

Viewing 13 replies - 1 through 13 (of 13 total)