Question

Web Client 11 Sessions not closing in Admin Console

Version 11 Web Client

Updated March 20

asked on March 7 • Show version history

We upgraded to Laserfiche 11 over the weekend. In one of our Forms processes we embed an iFrame of the Web Client. We are noticing in the Laserfiche Admin Console that the Web Client sessions are not closing out and as a result end users are getting the error:

"Sign in failed because the number of sessions has reached the licensed limit, or the user account has reached its session limit, or no named user license has been allocated to the user account. [9030]"

This issue was not happening in version 10 before the upgrade. We have opened a support ticket with our Solution Provider to investigate the issue further, but wanted to post it on here in case anyone has seen this problem before and if we come up with a solution I will post it here.

As an example of what we are seeing. the below screenshot shows a small sample of the connections we are seeing. Each colored block is for 1 user.

0 0

Replies

replied on March 7

Looking at this further, I don't believe that the issue is that the sessions are staying open, but rather why is the Web Client creating so many new sessions?

0 0

replied on March 9

On each of our web servers that has the Web Client installed I am seeing the following warnings and information messages in the Laserfiche\WebClient\Server\Operational logs:

I'm not sure what is causing each of the connections to be considered 'Invalid Connections'.

0 0

replied on March 9

It's interesting that, if you look at the Red user, most of the sessions were created at about the same time. Do you think that they viewed that many different instances of a Form, or would it have been a single Form that somehow caused all of those sessions to be created?

If the user is opening the Forms in the same browser, the web client should be reusing an existing session. Sessions are identified by session cookies, and the main cause of cookies not behaving the way you would like is related to domains. I would make sure that Forms and web client are hosted on the same domain, all urls use the FQDN, and all pages are https.

From a troubleshooting perspective, if you have a har trace that shows the problem occurring, you would be looking to see if the session cookie used for web client is the same across Forms instances or not.

0 0

View 1 previous reply

replied on March 9

@████████, I noticed that as well. The sessions are created at the same time and it is from the user opening a single task once in the same browser.

The Forms servers and Web Client servers are definitely on the same domain. There are 3 web servers involved and each has Forms, Web Client, and WebLink installed. All are part of the same LB. As for the URLs, that's a little different. We use a vanity URL, which is different than our domain. The link inside of the iframe that displays the Web Client uses the same vanity URL. All are using https.

We have tried to recreate the issue, but each time we try the multiple sessions doesn't happen, so our attempts to create a HAR file have been useless. Go figure, right? I will say that we are seeing the same behavior in both our Canada and US environments (share the same LFDS instance) as well as in test.

0 0

replied on March 9

I have been doing some testing tonight since it is about the only time others aren't in the system. I logged into the Web Client using an InPrivate browser window and checked the logs of the Web Client Server and I do not get the invalid session entries. I logged out of the Web Client and closed the browser window. I then opened a new InPrivate browser window and logged into Forms. After logging in I opened a Forms task that has an iFrame of the Web Client and then checked the Web Client Server logs. Sure enough, all 4 of the messages I posted above were present.

I thought that this problem might be related to some SSL errors I was seeing in the LFDS logs, but I checked those logs as I went through the steps I mentioned above and there were no new entries during that time.

0 0

replied on March 10

@████████, it looks like you are on to something with your comment about the cookies. I decided to try creating the HAR file again last night. This time I started capturing the data after the new window opened for the task in Forms. I went to the Network tab and went down the Name list line by line until I got to the first Request URL that included /Laserfiche. In the Response Headers section next to set-cookies it says SameSite-None and then a warning symbol. When I hover over the warning symbol it says, "This Set-Cookie header has invalid syntax."

I then went to the Cookies tab and checked the option to "show filtered out request cookies". In the section that then showed I found the cookies where the Domain and Path referenced the vanity URL, LFDS Server name, /LFDSSTS, /LFDS, and /Forms.

When I hover over the information icons for the items in the Domain column this is what it shows:

And the Path column ones show:

0 0

replied on March 10

That definitely doesn't look right. Is that problem somehow caused by the iframe embedding? Does it seem to operate correctly if you navigate directly to the web client?

0 0

replied on March 11

I think this might extend beyond the Web Client. Checking in on things tonight I saw this in the Admin Console:

0 0

replied on March 13

As an update, we do not have a resolution to this issue yet, but we do have an open support ticket with our Solution Provider and Laserfiche.

0 0

replied on March 15

Laserfiche has confirmed this as a bug to be fixed with a high priority. No current ETA.

0 0

replied on March 20 • Show version history

It appears I am likely experiencing this behaviour at a customer as well with plain Web Client Sessions no embedding. The issue does not seem to be unique to iFrame.

Interesting enough every WebLink 11 upgrade I have performed has this issue and there is a Hotfix I have been applying to address.

0 0

You are not allowed to follow up in this post.

Question

Question

Web Client 11 Sessions not closing in Admin Console

Replies

Sign in to reply to this post.