0

I went through the Legacy Lock API Deprecation documentation provided link

I have few clarifications

Its mentioned that by July 16, 2018 deprecated services will be removed.

And the criteria are given to identify whether I will get affected or not, below listed

  • Use of /usernamepassword/login endpoint directly from applications
  • Use of /user/ssodata endpoint directly from applications

In my application I have integrated auth0-js and I been using auth0.redirect.loginWithCredentials() function to send the username and password along with connection (database connection).

This function actually calls co/authenticate REST end-point.Does my current implementation needs a migration, will I be affected by services that will be stopped by Jul 16.

Another question: In the advanced settings of a tenant, its advised to disable the Legacy Lock API option under Migrations (see below image). If I do so I get pre-flighted error which is a CORS issue, any relation between this problem and previous question or how do I solve this issue

enter image description here

Keshan Nageswaran
  • 8,060
  • 3
  • 28
  • 45
  • What version of auth0.js are you using? How do users input their username/pass in your app (e.g. embedded Auth0 Lock, Auth0 Hosted login page, custom page in your app)? – BRass Jun 06 '18 at 13:52
  • @BRass I am using auth0-js V9.6.0 I have my custom login page in the app. I found the solution for this either use custom-domains or Provide a Cross-Origin verification page since I don't wanna use universal login – Keshan Nageswaran Jun 06 '18 at 13:55
  • 1
    I see. I ran into a similar dilemma when we used the embedded Lock. We decided to go to the Universal Login because attempting to do the Cross-Origin Auth route required third party cookies. We found that a percentage of our users didn't allow third party cookies. That's another thing to watch. https://auth0.com/docs/cross-origin-authentication – BRass Jun 06 '18 at 14:35
  • @BRass exactly!! I am looking into that concern as well, and third party cookie disabled situation only few browsers are supported for cross-origin auth, I feel like purchasing the custom-domains would be better option in that case. Universal login is not suitable for my project at this stage, since we have all custom pages set and our clients are used to it. But will see the feasibility and do the needful. Thanks for you valuable points – Keshan Nageswaran Jun 06 '18 at 15:26
  • One more note for you to consider. We also had 3-4 different login pages that people were used to. We changed our login to send a source parameter to the hosted login page, and then the hosted login page adjusted some colors and logos based on that. Not great, but it allowed us to go the universal login route and retain some flavor of what our users were used to. – BRass Jun 06 '18 at 16:59
  • @BRass any guidelines you referred to try out that method for universal login, and documentation mention saying that we can fully customize login/signup and the password reset page. but it's confusing that they don't give proper direction towards it – Keshan Nageswaran Jun 07 '18 at 05:22
  • This page explains universal login well, including how to customize the hosted page: https://auth0.com/docs/hosted-pages/login. An example of how to trigger the universal login (there are likely many), is to use Auth0.js `webAuth.Authorize()` call. See Auth0.js docs here - https://auth0.com/docs/libraries/auth0js/v9 – BRass Jun 07 '18 at 12:45

0 Answers0