Auth0.js: how to pass initialScreen to the hosted login page using authorize callback?

[thedavidmeister]

Just trying to send my users to either "log in" or "sign up" through the hosted login page.

Inspecting the config object passed to the hosted login page with a console log shows that initialScreen seems to be getting stripped if I provide it as an option to the authorize call on a WebAuth object.

[hzalaz]

@thedavidmeister it should be fixed in the latest auth0.js version

[devpascoe]

Nope 😭 not for me

this.auth0.authorize({
        redirectUri: location.origin + '/callback',
        connection: process.env.AUTH_DB,
        initialScreen: 'signUp'
})

[tonyneel923]

Any news on this?

[maxtuzz]

@hzalaz Can this issue be reopened? Still doesn't seem to be configurable for me.

[maxtuzz]

@tonyneel923 @devpascoe @thedavidmeister Actually, just fixed this:

Using auth.js:

this.auth0.authorize({
      initialScreen: 'signUp' // or login
});

Then within your hosted page, you can use this:

initialScreen: config.extraParams.initial_screen,
var lock = new Auth0Lock(config.clientID, config.auth0Domain, {
    ...,
    ...,
    initialScreen: config.extraParams.initial_screen,
}

[luisrudge]

thanks @maxtuzz. Is there something we can do to better document this?

[maxtuzz]

Documentation about how extra parameters work and are passed to lock would go a long way. Maybe using this as an example on how you can modify how lock behaves on a per-client basis.

For instance, to find out how our additional params were actually being delivered and served on lock I had to modify it to console out the contents of extra params.

[luisrudge]

Alright. I'll ping our docs team with this info! Thanks for your help and understanding! 🎉

[brandonarbini]

@luisrudge @hzalaz Would it be reasonable to create a generic way to pass extra params in the authorize URL? That way each option wouldn't need to be added specifically.

[luisrudge]

@brandonarbini you mean specifying unknown params in the .authorize method?

[brandonarbini]

@luisrudge Yeah, I want to be able to customize the hosted login page based on extraParams (as they're called in the default hosted login page HTML) passed to the page, but there doesn't seem to be a way to add more params to the authorize call. I think that's where it would be added at least. (Sorry, I'm pretty new to Auth0).

[luisrudge]

the authorize call shouldn't be removing the extra params. See here and here. It should just emit a warning (that you can disable).

The oauth/token call is actually cleaned up, as you can see here. What is the behavior that you're getting?

[brandonarbini]

@luisrudge Thanks so much for pointing me in the right direction. I updated to the latest auth0.js and tried again and it's working as expected. I'm not sure if it was the update or the way I was calling .authorize(), but it's doing its thing. 💯

[luisrudge]

uhuuuul 🎉

[AndreaRylander]

so I did what you said @maxtuzz and then Im able to use a custom page, but I dont understand how to send the users login-credentials to auth0 and get logged in, is it possible to get some guidance pls?

[luisrudge]

Hi @AndreaRylander, seems like you need some guidance on how to use the SDK. Please reach out to our amazing support team at https://support.auth0.com so they can better assist you with your scenario.

[devpascoe]

@maxtuzz is that work around still working? I can console.log the extra params in hosted page and see that the param is arriving ok but then setting initialScreen from there doesnt seem to do anything, hosted UI still loads login screen.

[devpascoe]

and how do i silence the warning in the console in auth.js about the extra param for initialScreen @luisrudge ?

[devpascoe]

So my hosted page was referencing lock v9 :/

[devpascoe]

but yes still would be good to silence the warning in js console for my custom param

[maxtuzz]

@devpascoe It is still working for me, yes. Make sure you are setting initialScreen to extraParams.initial_screen. It's important that the extra params are underscore separated and the assignment string is lower camel-case.

[wdoug]

Is there any reason this isn't provided as an option by default? It seems like a super common use case that I would have expected to be available out of the box. Forcing editing of a custom hosted page means that all our devs will have to update this on their dev accounts in order to get this functionality to work and cause confusion about it not working properly.

[deammer]

For the people that end up here, the authorize() call supports a mode parameter:

const auth = new auth0.WebAuth({
  clientID: '...',
  domain: '...'
});

// Show the sign-up screen
auth.authorize({ mode: 'signUp' });

[mansour-ahmed]

Anyone managed to directly navigate to the sign up page (Universal Login) using the auth. authorize function ?

I tried both:
1) auth.authorize({ mode: 'signUp' });
2) auth.authorize({ initialScreen: 'signUp' });

and doesn't seem to work.

[samuelmanzer]

Can confirm, it would appear that auth.authorize({ mode: 'signUp' }); no longer works