Email / Password login fails on new app in Development mode

[ilpvn]

Hi,

I have created a Vue.js SPA on a free account. It allows users to sign up, log in and log out of a Vue.js app I run locally. All signup, login and logout redirects function as expected.

Upon realizing that my team is already billed for an Auth0 account, I reproduced this Vue.js SPA in the dashboard of this billed account. I have updated my Domain and Client ID environment variables and restarted the app. I left the rest of the code untouched. I am using the auth0-spa-js library with Vue.js 2, with an Auth0 plugin and custom login, signup and logout buttons that call it.

Upon clicking on the SignUp button, to sign up as a new user, I get the following error message.

I double checked the settings on the 2 accounts but cannot find anything that looks login-related. I get the following error in the browser console: Uncaught Error: Error: At least one email, sms or social connection needs to be available.

I checked Authentication / Username-Password-Authentication in the dashboard, and the ‘Disable Sign Ups’ toggle is turned off.

I checked for any relevant difference between the dashboard settings of the new account where signup is functional, and my target billed account, especially on the Vue.js app settings, but could not find any at first sight.

Can you please help me troubleshoot this?

Thank you in advance

[marcelina.barycka]

He there @ilpvn ! Welcome!

Thanks for specific problem description!
Let’s check if there is some misconfiguration on the Auth0 tenant side.

For you SPA app, under “Connections” tab, you allowed Username-Password-Authentication connection (it’s not a passwordless connection type, quite the opposite).

In your custom Login page, I can see a custom script handling passwordless connection:

var lock = new Auth0LockPasswordless(config.clientID, config.auth0Domain, (...)

It would explain why you are receiving the error saying passwordless related steps are expected.

If you mean to use passwordless connection for you SPA app, please allow it for the app under “Connections” tab.

Does this solve your problem? Thanks!

[ilpvn]

Hi Marcelina!

Thanks for your answer.
Are you referring to this page: https://manage.auth0.com/dashboard/us/dev-4kiyagbm/login_page under Branding > Universal Login > Advanced Options? If so, can you please tell me a bit about it?

For context, the account was set up a few years ago by someone who left the company, and I have not used this custom settings myself when I experimented on the free account.

Thank you,

Isabelle

[ilpvn]

I toggled off the “Customize Login Page” button in the page I shared here-above.
When I click the “Log in with Auth0” button I created for the free account, I am redirected to my application’s homepage instead of Auth0’s login page.

I see that our billed account is using a custom domain. If I read correctly your page for custom domains (Custom Domains) I believed that I could use alternatively the Auth0 or the custom domains in calls as long as I remain consistent.

Given the error, I might be misunderstanding. I tried to update the environment variable for our front-end, which leads to the following error in the browser:

Uncaught (in promise) NS_ERROR_MALFORMED_URI: 
    loginWithRedirect auth0-spa-js.production.esm.js:1

This leads me to 2 questions:

• What should I adjust in our front-end and API code, and in the dashboard, when moving from Auth0 generic domain to a custom domain?

• Why would loginWithRedirect not be working neither with the custom nor the Auth0 domain?

Feel free to correct me if necessary, as I am a beginner with authentication flows.

[marcelina.barycka]

Hey Isabell!

These are good questions!

At this point it looks like the only thing that require correction is the connection type being allowed for the app in question. To be cohesive with the Login page settings (and assumably the conception implement in the old tenant of your team), please (1) go to the new Auth0 tenant → Applications → SPA app in question → Connections → Passwordless → enable email.

If you do not see this connection there as an option, it means the Passwordless (email) connection has not been yet configured in this tenant.

If so, please (2) go to you Auth0 tenant → Authentication → Passwordless and set it up there and back to (1).

In case of further issues, please send me a message here in the community with the Auth0 tenant name in question, because maybe you refer to some other Auth0 tenant then the one associated with the email address you registered in the community with. Thanks!

[ilpvn]

Hi Marcelina,

Here are the domain names of the tenants I am referring to:

• dev-6w4hy15cawy5fx8q: a new free account I created myself under techops@sosv.com.
  I am attempting to migrate my integration FROM it.
  Most features work as expected with this tenant
  (save an OpenSSL certificate issue, but this is a topic for another thread).

• dev-4kiyagbm: the legacy company account, created by another team member, that I can log into with my community email address. It is on a paid plan.
  I am attempting to migrate the integration I am building INTO this account in order to benefit from the paid plan we are already being billed for.

The 2 tenants seem to have different settings, which apparently need some code updates that I am struggling to identify.

On tenant dev-4kiyagbm, the passwordless email connection is available already (cf. screenshot hereunder). I tried to toggle it on but I keep getting the NS_ERROR_MALFORMED_URI error above.

On my Vue.js front-end, I tried using each of the 2 following values for the domain environment variable:

# BILLED ACCOUNT
VUE_APP_AUTH0_DOMAIN=dev-4kiyagbm.auth0.com # Auth0 domain
VUE_APP_AUTH0_DOMAIN=auth.forfounder-staging.sosv.com # SOSV custom domain

I am then providing this variable to the Auth0Plugin as hereunder:

Vue.use(Auth0Plugin, {
  domain: process.env.VUE_APP_AUTH0_DOMAIN,
   ...
}

[marcelina.barycka]

Alright, thank you for this!
I think the NS_ERROR_MALFORMED_URI error that appears after enabling email connection can be a good direction for further investigation.

Based on the paid tenant metadata, I can see that for the email connection, the sign up option is disabled. Can you please change it and test signing up again?

Another thing to check is the section of our documentation describing setting up features under custom domain. You can find here for example what to do in case of Custom login page that is supposed to work under custom Auth0 domain.

Hope this will help, but if not, please let me know and we will investigate it further. Thanks and have a great weekend!

[ilpvn]

Hi Marcelina,

I went to “Passwordless Connections”, clicked “Email” and toggled off “Disable sign up”.

I tested signing up again and keep getting the NS_ERROR_MALFORMED_URI: error.
I also tried adding a .us suffix in the URL, to no avail.

[ilpvn]

I have already toggled off the “Customize Login page” option to use the default Login page.

From the documentation you shared with me, “if you use the default login page without customization, you do not need to make any changes.”

I am calling .loginWithRedirect from a Vue protoype this.$auth0, that I am defining and exporting from the following file:

import Vue from “vue”;
import { createAuth0Client } from “@auth0/auth0-spa-js”;

let instance;

export const getInstance = () => instance;

export const useAuth0 = ({

onRedirectCallback = () =>
window.history.replaceState({}, document.title, window.location.pathname),
redirectUri = window.location.origin,
…pluginOptions
}) => {
if (instance) return instance;

instance = new Vue({
data() {
return {
auth0Client: null,
isLoading: true,
isAuthenticated: false,
user: {},
error: null,
};
},
methods: {
loginWithRedirect(options) {
return this.auth0Client.loginWithRedirect(options);
},

  logout(options) {
    return this.auth0Client.logout(options);
  },

  getAccessTokenSilently(o) {
    return this.auth0Client.getTokenSilently(o);
  },
},

async created() {
  this.auth0Client = await **createAuth0Client**({
    ...pluginOptions,
    **domain: pluginOptions.domain**,
    clientId: pluginOptions.clientId,
    authorizationParams: {
      audience: pluginOptions.audience,
      redirect_uri: redirectUri,
    },
    useRefreshTokens: true,
    cacheLocation: 'localstorage',
  });

  try {
    const search = window.location.search;

    if (
      (search.includes("code=") || search.includes("error=")) &&
      search.includes("state=")
    ) {
      const { appState } = await this.auth0Client.handleRedirectCallback();

      onRedirectCallback(appState);
    }
  } catch (error) {
    this.error = error;
  } finally {
    this.isAuthenticated = await this.auth0Client.isAuthenticated();
    this.user = await this.auth0Client.getUser();
    this.isLoading = false;
  }
},

});

return instance;
};

export const Auth0Plugin = {
install(Vue, options) {
Vue.prototype.$auth0 = useAuth0(options);
},
};

In my Vue.js 2 application main.js file, I am defining Auth0 as follows:

Vue.use(Auth0Plugin, {

domain: process.env.VUE_APP_AUTH0_DOMAIN,
clientId: process.env.VUE_APP_AUTH0_CLIENT_ID,
redirectUri: process.env.VUE_APP_AUTH0_CALLBACK_URL,
audience: process.env.VUE_APP_AUTH0_AUDIENCE,

onRedirectCallback: (appState) => {
router.push(
appState && appState.targetPath
? appState.targetPath
: window.location.pathname
);
},
});

I defined my domain as follows:

VUE_APP_AUTH0_DOMAIN=dev-4kiyagbm.auth0.com

Any other useful information I can provide you, lmk.

[marcelina.barycka]

Hi Isabelle,

Thanks for the config file details, it looks good.

If you go to your Auth0 tenant → Authentication → Passwordless → Email → Try it: you may notice either the warning message saying the “Identifier First” has to be enabled or as a result you will be showed with the login page prompting users to enter their both ID and Password, which is a misconfiguration.

Users are suppose to be prompted first only with their identifier (email) → next an email with the verification code is being sent → users see another page prompting them to provide the receive verification code.

To set it up for the New Universal Login, please go to Authentication → Authentication Profile → and choose the “Identifier First”.

It works for me this way. Let us know how it goes for you. Thanks!

[ilpvn]

Hi Marcelina,

I changed the 2 settings you advised and activated “Identifier First”.
The warning message, that was initially displayed, disappeared.
I tested the functionality and it works from the dashboard.

However, I keep having the URI error when I try to log in or sign up with Auth0 in my application.
Could my redirect URL (callback URL in my environment variables) be configured incorrectly?
It is a development URL: http://localhost:8081/callback.
I also tried to edit it to our application’s login page but both fail.

[marcelina.barycka]

Hi Isabelle,

Your callback URL looks correct but the Identity Provider (Auth0 tenant) has to be aware of all your redirect URIs. Creating a comma separated list of all your redirect URIs under the Allowed Callback URLs for the app in question is required. At this point, your [Preformatted text](http://localhost:8081/callback) is not being there.

It might be a good idea to scan the quickstart once again quickly to double check if all steps have been completed.

Thanks again for such specific problem description on each of your replay, it helps a lot with the investigation - win-win

Another way to capture insight on what’s happening while you test the authentication / authorization is to generate the HAR file. It contains sensitive data so once in your possession, please don’t share it as a public replay - rather please use what you have learned from it by creating a new topic and once asked, share the file by sending the private message to the one that works with you on a new issue. Thanks!

[ilpvn]

Hi Marcelina,

Thank you for the update.

I am now having the same URI error in the new (free) account.

I double checked the callback URL and the one specified in my application in Auth0 dashboard is identical to my environment variables. I fully read the paragraph under it, and it indicates that the HTTPS protocolfin is required for callback URLs. (screenshot hereunder)

• This seems to contradict the information that I found here: Test Applications Locally (second screenshot). Is it possible to use HTTP for callback URLs?

• Our team’s localhost setup uses HTTP. If HTTPS is required, how can I test Auth0 integration against our development environment?

Thank you!

I will have a look at the quickstart again, then at generating the HAR file when I get the time.

[sgo]

Hi @ilpvn - cross posting here as you had an open support ticket with us.

You can absolutely use HTTP for testing purposes in your allowed callback URLs, the text is just saying you should use HTTPS, and production applications should not have any “localhost” or HTTP allowed callback URLs set for security once they are live.

[ilpvn]

Thanks Steve, your answer is very clear.
I do find the mention of https:// in the Allowed Callback URLs a bit confusing though. Adding a sentence along the lines of your answer might help users understand better how it works.

[ilpvn]

Hi Marcelina,
The link you shared with me is meant for Vue.js 3. I am using Vue.js 2.
So I am using a different packahge (auth0-spa-js and not auth0-vue) and have used this tutorial for set up. I have reviewed all the setup regardign Vue.js till the redirect and I have completed all steps.

[ilpvn]

Hi Marcelina,

I finally identified the issue. I was using comments in my .env file:
AUTH0_DOMAIN = "the right string" # comment.
Commenting on the same line as code in the environment file was generating an error.

You can close this thread now, thank you.