Handling of newline characters in custom login scripts when updating script via the Management API

Help
1

Hi,

I’m using the Management API to update custom database connection scripts (login) and noticed that embedded \n characters in my customScripts.login JSON string value do not get interpreted as expected when viewing the scripts from the Auth0 dashboard. The script appears as a single long line with \n shown inline instead of being interpreted as newline. It doesn’t appear to cause any issues with the function working, but it would be nice to have the script more readable in the dashboard for debugging, etc.

If I go in reverse, and edit a script interactively from the dashboard with newlines, do a get connection via the Management API, and send back the same string Auth0 gave me (again with embedded \n characters) I see the same issue.

Any tricks to working with newlines to make this work or is this just an expected side-effect of using the API?

2

I don’t see why newline wouldn’t work - the default login script returns the following, which displays correctly (with newlines) in the dashboard:

"customScripts": {
      "login": "function login (email, password, callback) {\n  // This script should authenticate....
  }

One thing to ensure is that there is no space between the preceding code and the newline character \n. E.g.

"function login (email, password callback) { \n......."

Note the space between the { and the \n.

3

I have no spaces and still see the issue. Here’s my dashboard view of the script edited inline:

![alt text][1]

Fetching the connection object via the management API it looks like what I’d expect:

![alt text][2]

Now if I take the string Auth0 returned to me above (i.e. the string literal “function login (email, password, callback) {\n var profile = {email: email};\n return callback(null, profile);\n}\n”) and just echo it back to the update call, Auth0 returns this (note the escaped newline \n):

![alt text][3]

and when I refresh the dashboard the script looks like this:

![alt text][4]

4

Well it appears to be PAW doing something strange here. Just tried the same test via Postman and worked fine. Thanks for the reply.

…Trevor