I am stuck on how to actually provide values to the @@config@@ object, which is used in the hosted login page generated code: https://manage.auth0.com/#/login_page
Is @@config@@ a placeholder, and if so what is the object I should provide to it? If it isn’t a placeholder, then how is this used? How does it work? the documentation here Auth0 Universal Login gives examples of adding to the config object, but I don’t know what it is in the first place.
Any help on using the hosted page with the @@config@@ is much appreciated.
2 Likes
The @@config@@ construct is a placeholder that will be replaced by the runtime. The documentation you linked to shows how you can include that placeholder in the hosted login page and get a Javascript object from the value that will be provided at runtime. The information contained within this value will be provided automatically by the runtime based on your configuration and also possibly based on parameters received from the client application.
You don’t directly control most of the contents within this object, however, as mentioned in the linked documentation, if you pass additional query string parameters when initiating the navigation to the hosted login page from your client application then these extra parameters will be available at config.extraParams; assuming you processed the contents of the @@config@@ into a variable named config like it is shown in the documentation:
var config = JSON.parse(decodeURIComponent(escape(window.atob('@@config@@'))));
From your post it seems your goal is to pass additional parameters so you should focus on the contents of config.extraParams after ensuring that you pass the additional data through query string parameters.
2 Likes
Thanks for that. I think I misunderstood how it is meant to work. I was copying the code from the hosted login editor, which is not correct.
Next question is how do I actually plug in a hosted page into my MVC app? Do I redirect to the URL for the login? I am needing a second login form in a new “area” of an MVC app, and am now wondering if this is the right approach to use a hosted login page?
The hosted login page is meant to be used in a flow where the end-user is redirected there for authentication/authorization and then the response is handed back to the client application as part of another redirect. This centralized login approach has a lot of benefits, but implies full navigation from one place to another (similar to Google going to accounts.google.com for login purposes).
I would go with the hosted login approach unless you have very specific requirements that force you to provide embedded login experience directly in the client application.