Select to view content in your preferred language

Experience Builder: Random "Cannot read properties of null (reading 'trim')" Error During OAuth Login in Deployed App

353
5
06-11-2025 11:31 PM
Labels (1)
BasWest
Occasional Contributor

Hi all,

I'm encountering a sporadic issue with an ArcGIS Experience Builder (Developer Edition, version 1.17) application after deployment. ArcGIS Enterprise version 11.1

Localhost Behavior

When I run the app on localhost, it works perfectly every time — the OAuth login pop-up appears, credentials are acquired, and the map loads as expected.

Deployed Behavior

After deploying the app to a web server (tested on both Nginx and IIS), the application randomly fails during load. The ArcGIS login pop-up sometimes does not appear, and the following error is shown in the console:
Console Errors:

TypeError: Cannot read properties of null (reading 'trim')
at Module.w [as normalize] (init.js:116:221)
at k._sanitizeUrl (IdentityManager.js:35:388)
at k.findOAuthInfo (IdentityManager.js:13:222)
at registerOAuthInfo ...
at initToRegisterOAuthForMainPortalAndAGOL ...

Other related messages:

  • Create data source error
  • onCreateDataSourceFailed
  • Creating map failed

    These errors point to null.trim() being called during the authentication process, apparently in _sanitizeUrl() or findOAuthInfo() from IdentityManager.js.

    Important Points to note:

    • Issue is intermittent – sometimes the app loads and logs in as expected.
    • Other times, it fails silently (no login popup), then throws the above error.
    • OAuth config is correctly set in config.json.
    • This issue does not occur in development (localhost) but only after deployment

       

      Has anyone else experienced this issue before?

      Any insight or guidance would be greatly appreciated.

      Thanks!

5 Replies
Allen_Zhang
Frequent Contributor

I tested with an app deployed to an nginx server, but I couldn't reproduce the issue.

My suggestion is to test on another physical machine or virtual machine to rule out environment issues. If the problem can still be reproduced on another machine, then it can be confirmed as a software issue.

0 Kudos
BasWest
Occasional Contributor

Thanks for testing @Allen_Zhang . Unfortunately deploying on different machines does not resolve the issue. There seems to be no pattern when the application is failing and when it is loading correctly. 

Also, a colleague of mine tested with Experience builder 1.16 since I created this post and with that version, she could not reproduce the issue.

0 Kudos
Allen_Zhang
Frequent Contributor

It might be an issue specific to the app.

Try to deploy an empty app for testing. If the empty app does not have the same issue, it indicates that the problem lies within the app.

From there, you can use the process of elimination (removing half pages/widgets and testing the other half) to identify which part of the app is causing the issue.

However, since the problem is intermittent, this could be challenging to diagnose.

If the app can be shared, I can do some tests on it.

0 Kudos
TimWestern
MVP

I would add the following questions.

When you say you deploy it? the 1.17 version and it is throwing these errors, and you tried it with 1.16.  Is there anything different in the steps you take to deploy it?

For example?  Is it an entire 'app folder' being copied? to a server?

0 Kudos
BasWest
Occasional Contributor

Since I made this post, I found another one on this forum that describes something very similar (if not the same)

JavaScript error when using locally hosted ArcGIS ... - Esri Community

The poster concludes that it has to do with the inclusion of a custom widget (not the widget itself, but the implementation in the app in combination with the table widget). We also have a custom widget and the table widget included so that makes sense.

Second, we also contacted Esri support about this issue. After investigating they concluded that there is an issue in experience builder 1.17 that probably causes this behavior and that will be addressed in 1.18. So, we will temporarily revert to 1.16 and in a later stage go to 1.18 if nothing else pops up.