Structure of @@config@@

Help
,
1

I’m trying to have our HLP displaying locally in a browser so that I can interactively work with the layout and logic. We’ve got a lot of JS stuffed in to the page, but that all fails once we hit the CONFIG = JSON.parse(decodeURIComponent(escape(global.atob(“@@config@@”)))); line. I would like to put this into a try/catch block with the catch block creating a plausible object.

Is the config object documented anywhere?

I’m hoping that @jmangelo will be available to answer this.

2

The notion of that configuration object is documented here although it does not go into all the details (every property available under that object) and to be honest I believe some of them may be considered implementation details where the lack of documentation is intentional.

The config object contains the set of configuration values that adjusts the behavior of the Hosted Login Page at runtime.

For example config.extraParams is covered by the same documentation linked above, but the full structure of properties like config.internalOptions may be something that won’t ever be documented as it can be considered an implementation detail. Having said that I personally think that even if parts of this needs to be kept as an implementation details there are some that may and should be better documented so I’ll chase this up internally.

Meanwhile if the goal is to have this running locally for the purposes of development (with the consideration that not all logic could be tested to completion locally as you would still be running this outside of the Auth0 service) I would consider the following:

  • instead of changing the template to have compensating logic (the try/catch) for when it’s running locally I would serve the template file from a simple HTTP server that does the placeholder replacement before sending the response to the browser.
  • generate the placeholder value by performing the inverted set of operations used in the template; something like var placeholder = window.btoa(unescape(encodeURIComponent(JSON.stringify(config)))); where config would be the configuration object that you would want your local template page to receive.

The above still leaves you with the problem of creating that configuration object before serving the template, but has the benefit that you don’t do any actual modification to the template just for the purposes of development. With regards on how to build that configuration object that could be converted to placeholder it will depend on how much your hosted login page templates uses from the configuration placeholder and again, it would never be an equivalent experience. Personally, given this is to speed up development I would just navigate to the hosted login page for real and in the browser tools JSON.stringify(config) and start with that. Nonetheless I will still follow this with regards to more documentation around this object as this seems to indeed be a gap.

3

Thanks @jmangelo for the detailed answer. You’ve covered the following points:

  1. You will work internally to deal with the documentation gap.
  2. Some details are intentionally undocumented for security sake. I understand that but (honestly) it raises a small concern about using security through obscurity techniques.
  3. Running an HTTP server is smart, and for devs working on this longer term, we will put that as an option. For those of us who are only dealing with a story or two and then back to another team, being able to have a static local .html file is less overhead.
4

This was sufficient for getting our code running from a file:/// local file.

	var CONFIG = {};
	try {
		CONFIG = JSON.parse(decodeURIComponent(escape(global.atob("@@config@@"))));
	} catch (e) {
		// Minimum data to prevent errors
		CONFIG.auth0Domain = "example.com";
		CONFIG.clientID = "123456789";
		CONFIG.internalOptions = {};
		CONFIG.extraParams = {};
	}

We simply needed enough of an object to get through the initial painting of the HTML to the browser without crashing out the JS thread. (We use a variety of onclick events in the UI elements to make the forms look and work nicely. When the parse would fail, all of the onClick events would become inoperable.)

5

Yes, on point 1 as I already asked the docs team to have a look into what’s possible. For point 2, I may not have expressed myself correctly, certain details may not get documented, but if they are not it is not for security sake; it’s just that they are subject to change without notice (like simply renaming the name of an internal undocumented property that happens to be exposed on that object).

6

Thanks for the clarification on point #2! I fully understand that situation.