We started having a problem where Web Client users couldn't load all panes immediately after login, but if they closed the tab and entered the site again it would work.

When you install the Web Client the app name is set to "Laserfiche" by the installer. (Side-Note: I thought it used to be "laserfiche", did this change in a build somewhere?)

However we found that when you visit the site https://domain/Laserfiche, there is internal code which changes this site to https://domain/laserfiche.

Now if you try to change the site back to https://domain/Laserfiche it can break some internal calls since there seems to be some case sensitivity in play. This is what was causing the issue. But not because the user was manually doing this in their browser.

Instead, there is more internal code that can cause this to happen automatically and break the system.

If you already have a session saved in your browser and you can immediately login, then your fine, the url changes to /laserfiche and stays that way.

If you need to login and are re-directed to the STS server, after entering your credentials, the url changes back to /Laserfiche. Now we can't load information because of the mismatch with internal requests and the active URL.

The quick fix is to manually change the url in the browser back to /laserfiche and the fix we have in place now is to change the IIS application name to /laserfiche after finding the STS was using the IIS application name to change the active URL.

So we know we need all requests to match case, maybe we either need the installer to use /laserfiche or the internal requests to use /Laserfiche.

Here is example of both good and bad requests where only a difference in active URL resolves the problem

The thought is that maybe the case sensitivity is in the Cross-site request forgery rules.

First a failure condition after the URL gets changed to /Laserfiche

Then a successful request after just updating the URL to be /laserfiche in the browser