You are viewing limited content. For full access, please sign in.

Question

Question

document.domain mutation is ignored

Web Client Version 11 Self-Hosted
Updated one day ago
asked on December 20, 2024 • Show version history

I have been troubleshooting an issue with trying to get the Web Client 11 to work in a DMZ environment for the past few months. Laserfiche Forms 11 is currently working on the same server, as well as LFDSSTS.

The environment is like so:

  • DMZ Server: The server is joined to domain-name.local. There is an alias that points laserficheweb.domain-name.com to it.
  • Repository Server: The server is joined to domain-name.local.
  • LFDS Server: The server is joined to domain.com.

 

All have valid SSL/TLS certificates. As I mentioned, Laserfiche Forms is configured and working in the same environment.

I do not currently have the Web Client forcing LFDS authentication, so you are first presented with the Web Client login page. When I try to log in using LFDS Authentication, which uses SAML Okta, it authenticates me in Okta but then sends me back to the Web Client login page.

Looking in DevTools -> Console I am seeing this message a few different times:

document.domain mutation is ignored because the surrounding agent cluster is origin-keyed. (anonymous) @ browse.aspx?repo=repoName:17

If I click the link for that file I see the following:

Everything that I have read about this error from Google and Microsoft, dating back to 2023 talks about how this is no longer supported.

So I have two questions:

  1. Any idea why I would be seeing this error message in the Web Client, but not Forms?
  2. Does the code mentioned in the screenshot need to be updated since it is no longer supported by Google or Microsoft browsers?

 

I am using Web Client v11.0.2409.35.

0 0

Replies

replied on December 20, 2024

Did you run Web Client's EndpointConfigUtility to give it the relevant LFDS connection info? Getting sent back to the Web Client login page after successful LFDSSTS auth is suggestive that Web Client is unable to validate the STS token with LFDS. There may be event log messages indicating that.

Do the domain-name.local and domain.com AD domains have a trust relationship?

0 0
View 5 previous replies
replied on December 20, 2024 • Show version history

Yes, I have configured the Web Client EndpointConfigUtility.

I have found in the Web Client\Server\Operational logs the following error. It happens about every minute. I'm not sure if it's related or not because I'm not sure what the UpdateADCacheTimer is. And yes, there is a trust between the domains.

Log Name:      Laserfiche-WebClient-Server/Operational
Source:        Laserfiche-WebClient-Server
Date:          12/20/2024 3:43:06 PM
Event ID:      1
Task Category: AdministrativeMessage
Level:         Information
Keywords:      Session0,Session1,Session2,Session3
User:          IIS APPPOOL\WebAccessAppPool
Computer:      XXXX
Description:
The server is not operational.

Operation: UpdateADCacheTimer
  Message: Exception details:
  Message: The server is not operational.

  Stack trace:    at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
   at System.DirectoryServices.DirectoryEntry.Bind()
   at System.DirectoryServices.DirectoryEntry.get_AdsObject()
   at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne)
   at Laserfiche.WebAccess.Common.ActiveDirectoryAccountCache.UpdateCacheInternal_OLD(String domain, Boolean fastBind)
   at Laserfiche.WebAccess.Common.ActiveDirectoryAccountCache.UpdateCache(String domain)
Exception encountered, stack trace:
  Laserfiche.WebAccess.Common.ActiveDirectoryAccountCache.UpdateCache
  Laserfiche.WebAccess.Global.UpdateADCacheCallback
  Laserfiche.WebAccess.Common.Util.TimerWrapper.timerCallbackWrapper
  System.Threading.ExecutionContext.RunInternal
  System.Threading.ExecutionContext.Run
  System.Threading.TimerQueueTimer.CallCallback


Event Xml:
<Event xmlns="http://schemas.microsoft.com/win/2004/08/events/event">
  <System>
    <Provider Name="Laserfiche-WebClient-Server" Guid="{e1931bbe-b561-55ce-776e-86d128b8cd81}" />
    <EventID>1</EventID>
    <Version>0</Version>
    <Level>4</Level>
    <Task>65533</Task>
    <Opcode>0</Opcode>
    <Keywords>0x8000f00000000000</Keywords>
    <TimeCreated SystemTime="2024-12-20T20:43:06.5664057Z" />
    <EventRecordID>33695</EventRecordID>
    <Correlation />
    <Execution ProcessID="4308" ThreadID="1724" />
    <Channel>Laserfiche-WebClient-Server/Operational</Channel>
    <Computer>XXXX</Computer>
    <Security UserID="S-1-5-82-90942142-69841976-3763844167-1815131087-745571325" />
  </System>
  <EventData>
    <Data Name="message">The server is not operational.

Operation: UpdateADCacheTimer
  Message: Exception details:
  Message: The server is not operational.

  Stack trace:    at System.DirectoryServices.DirectoryEntry.Bind(Boolean throwIfFail)
   at System.DirectoryServices.DirectoryEntry.Bind()
   at System.DirectoryServices.DirectoryEntry.get_AdsObject()
   at System.DirectoryServices.DirectorySearcher.FindAll(Boolean findMoreThanOne)
   at Laserfiche.WebAccess.Common.ActiveDirectoryAccountCache.UpdateCacheInternal_OLD(String domain, Boolean fastBind)
   at Laserfiche.WebAccess.Common.ActiveDirectoryAccountCache.UpdateCache(String domain)
Exception encountered, stack trace:
  Laserfiche.WebAccess.Common.ActiveDirectoryAccountCache.UpdateCache
  Laserfiche.WebAccess.Global.UpdateADCacheCallback
  Laserfiche.WebAccess.Common.Util.TimerWrapper.timerCallbackWrapper
  System.Threading.ExecutionContext.RunInternal
  System.Threading.ExecutionContext.Run
  System.Threading.TimerQueueTimer.CallCallback

</Data>
  </EventData>
</Event>

0 0
replied two days ago

I remembered after reviewing one of your other posts about the /lfdssts/claimstest page, so I decided to see if it came back with anything after authenticating to Okta and it shows that I am authenticated, and it shows the various claims as I would expect... and the mystery continues.

0 0
replied two days ago

The claimstest page simply shows you the contents of your STS token in a human-readable format. I think it's clear you're being issued a valid STS token especially given you can log into Forms with it. Good to sanity check, but STS wouldn't have sent you back to the referring application otherwise. The issue is web client not accepting that token for whatever reason.

0 0
replied one day ago

I've opened a support case with our SP, who has opened one with Laserfiche Support. I'll update this thread as I learn more.

0 0
replied one day ago • Show version history

LF Case #?

0 0
replied one day ago

Just asked my SP for it. You might find it faster than they respond.

0 0
replied one day ago

The LF Support ticket number is 243015.

0 0
replied one day ago

Thank you, Nevin!

0 0
replied on January 14 • Show version history

@████████, just for clarification, which server should I be entering in the Web Client EndpointConfigUtility? I have an LFDSSTS on each DMZ server. Do I enter the DMZ server or the LFDS server itself? I have tried both and neither has solved my issue.

0 0
replied on January 14

The LFDS server itself. Here's the way I remember:

The EndpointConfigUtilities tell the application where to contact to validate the LFDSSTS tokens they receive. The LFDS service is what validates those tokens by saying "Yes, I issued that and it's valid."

0 0
replied two days ago

Thank you for the clarification. I'm not sure why it would be having an issue with the Web Client and not Forms.

0 0
You are not allowed to follow up in this post.

Sign in to reply to this post.

Details
Related Posts
Loading ...