Question

Forms - If you are not redirected automatically, follow this url

Forms

Updated January 30, 2024

asked on December 8, 2021

Hi,

We occasionally have this endless loop happening on an idle browser session. We currently have Forms 11 (11.0.2106.10331). This lasted for more than 7 minutes then it all of a sudden woke up. The other workaround that I have is to recycle the FormsAppPool, which kills all sessions.

Event log from Windows Server (hundreds/thousands of them)

Then once it snapped out of the endless loop, this event came up:

Any idea on how to prevent this from happening, or is it a bug? I saw this article:

https://answers.laserfiche.com/questions/183801/Issue-when-trying-to-access-Forms

But it says it was fixed in a previous release, but I'm still experiencing the same issue in Forms 11. It seems related to the session in the browser.

0 0

Answer

APPROVED ANSWER

replied on January 29, 2024

Success! My VAR and Laserfiche Support was able to come up with the answer for my case. Forms and LFDS reside on different servers, accessed via aliases (Laserfiche and LaserficheForms). FormsConfig was configured with the more friendly alias (https://Laserfiche/LFDSSTS) instead of the FQDN (https://Laserfiche.my.domain). When Forms times out, LFDSSTS sends a request to Forms to clear the cookie, but because it was seen as being on different domain, the cookie wasn't being cleared, causing the loop.

After making that change, when Forms times out I'm either sent to the LFDS login page or the draft saved page, depending on whether I'm submitting a form or not. Of course, the certificate has to include the FQDN as SANs, as well.

1 0

replied on January 30, 2024

For us, our FQDN is for example domain1.com. But we want every user who accesses any Laserfiche service with domain2.com. Both domains are included in our wildcard SSL.

In that screenshot that you have, we have
Laserfiche Forms Host URL = laserficheforms.domain2.com/Forms/
Directory Server STS URL = laserfichests.domain2.com/LFDSSTS/

But then in our Forms Server -> "Primary Forms Server URL", we had the FQDN of the primary server.
server1.domain1.com/Forms/

Is this kind of the same setup that you had? You then changed the "Forms Server - Primary Forms Server URL" to have domain2 instead of domain1?

0 0

replied on January 30, 2024

Originally, I didn't have the domain name in the Authentication section. Yes, it gives that in the example, but I ignored that to make the URL more friendly, which is why my setup started having issues. Because there was no domain in the URL, the servers saw them on separate domains. We only have one domain and one Forms server, so the host and primary are the same.

Since your primary LFForms server is on a completely different domain it makes sense that could be the issue for you, similar to mine. Based on the info from Support, when a session in Forms times out, LFDSSTS attempts to clear your Forms cookie. It struggles to do that if the two servers are on a different domain. I wonder if having your LFDS on the same domain as your primary server would make a difference, even if the host is on a different domain? When you connect to your Host on domain2, is the cookie for that host or the primary?

Keep in mind, I barely know what I'm talking about here. I'm just analyzing based on my recent experience.

0 0

Replies

replied on December 8, 2021

Hi Patrick,

Sorry to hear you're encountering this issue. There's a small possibility that it's related to Forms app pool timeouts. Could you try running the IIS settings optimization script I posted here on your Forms server and let me know if that helps?

0 0

replied on December 8, 2021

Hi Samuel,

I'll give it a whirl. We had already changed the app pool for Forms/LF web client to Always Running, but didn't have the other stuff.

I'll update this post within a week to give an update.

Thanks for the quick reply!

1 0

replied on December 10, 2021

Just an update, it did not help, FYI.

1 0

replied on December 10, 2021

Well, was worth a try. Thanks for reporting back.

0 0

replied on December 8, 2021

We need more information to troubleshooting your issue. Can you open a support case with your SP?

1. The version of Laserfiche Directory Server

2. The screenshots for Forms Server tab and User Authentication tab for Forms Configuration site.

3. The event logs for Forms.

0 0

replied on December 8, 2021

Will do, thanks!

0 0

replied on December 18, 2023

Hi Patrick,

Did you ever come up with a resolution? I'm on Forms v11.0.2307.40556 with a similar problem that started after enabling Session Timeout in FormsConfig. In my case, however, the site never wakes up, even after restarting the browser. My only workaround is to use the FQDN of the site instead of just the friendly name. I might try recycling the FormsAppPool to see if that works like it did for you.

0 0

replied on December 18, 2023

We still occasionally get the issue (we are on 11.0.2307.40556 as well), but much less frequently since my post from 2021. The fix is still to recycle the app pool, or like you said, use the other URL.

1 0

replied on January 19, 2024

Update! Laserfiche support was able to replicate the issue, as were the developers. Knowing how quick they are to implement change requests and the fact they've seen this before, I would expect a fix to be forthcoming.

My workaround for now was to set the Forms timeout to 9 hours.

1 0

You are not allowed to follow up in this post.

Question

Question

Forms - If you are not redirected automatically, follow this url

Answer

Replies

Sign in to reply to this post.