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

Question

Question

Office Plug-in - A connection to Laserfiche web client cannot be made. Refresh Laserfiche web client and try again

asked on September 13, 2023

I have two Laserfiche environments; both Web Clients are version 11 (11.0.2304.16).  My production environment works when I attempt to edit a document with MS Office.  In my development environment when I attempt to edit a document, I get the following error:

A connection to Laserfiche web client cannot be made. Refresh Laserfiche web client and try again.

The magic number in GZip header is not correct. Make sure you are passing in a GZip stream.

   at Laserfiche.OfficePlugin.Common.DocModel.OPArtifactFactory.FromURL(IWin32Window hwnd, WebServiceArguments webURL, String filter) in c:\agent\13198\s\src\SaveToLaserfiche\Common\DocModel\OPArtifactFactory.cs:line 228

 

I'm not sure how to fix this - I'm assuming that Webtools and Office integration are fine on my machine as it works on documents in my production environment.

 

0 0

Replies

replied on September 14, 2023 Show version history

Hmmm... Is it using an https Web Client url https://<fully-qualified-domain-name>/... with a valid/trusted certificate?

Are the two IIS configured in the same way? Compression module, URL Rewrite module?

As a test, you could expose the test LF Server via the production Web Client to rule out LF Server configuration issues.

0 0
replied on September 20, 2023 Show version history

Everything looks to be set the same between both environments.  Today I attempted to save using the Office Add-in from Excel to a repository in the DEV environment and got this error:

One difference between the two environments is that we have been testing in our Development environment the disabling of the following protocols and cipher suites:

Protocols : TLS 1.1, TLS 1.0, PCT 1.0, SSL 3.0, SSL 2.0

Ciphers: NULL, RC2 40/128, RC2 56/128, RC2 128/128, RC4 40/128, RC4 56/128, RC4 64/128, DES 56/56, RC4 128/128, Triple DES 168

Is the Office Plug-in / Office Add-in dependent on any of the disabled items?

 

 

0 0
replied on September 22, 2023

OK it doesn't seem to be related to the Protocols & Ciphers as we disabled them in our Production environment this morning and the Office plug-in works after the changes.

0 0
replied on September 25, 2023

Are there any other errors recorded in the event log of the web client machine around that time? I've seen it happen that an error disrupts the compression implementation - the header promises compression, but it isn't applied to the response.

0 0
replied on September 27, 2023

Nothing in the Web Client event logs.  We did configure kerberos in addition to the disabling of protocols & ciphers in our production environment yesterday, so now the office plug-in doesn't work there either.

So, could it be related to kerberos?

 

0 0
replied on September 27, 2023

Can you say more about how you set up Kerberos? Web client should exempt the urls that Office Plugin uses from requiring Kerberos, so that shouldn't have an impact. But if enabling it broke what was working, it definitely suggests a connection. Do you get the same error you reported above?

0 0
replied on September 28, 2023

Yes it is the same error.

We enabled Kerberos for a two-hop configuration running services with a domain service account (using the kerberos whitepaper, but had to get help from our VAR with some undocumented settings to work with non-RC4 ciphers).  Our web client server is the front end and the server running Laserfiche server is the backend.  We also had to do "resource-based delegation" in order for Edge to work without extra configuration via GPO on clients to trust unconstrained delegation.

In IIS on the Laserfiche site, we disabled Anonymous Authentication and enabled ASP.NET Impersonation and Windows Authentication.  In the configuration Editor under windowsAuthentication we set useAppPoolCredentials to True.

We set the WebAccessAppPool to use ApplicationPoolIdentity.

0 0
replied on October 3, 2023

Hey Brian,

 

I am working with Craig on this issue. you mentioned you had seen this error before. What was the cause of that error in those scenarios? 

0 0
replied on October 3, 2023

Well, the message implies that the http response headers say that the response is compressed, but the http client finds that the http body is not a gzip stream. That is something that web client has done in the past, usually triggered by an error on the server side. The error response page was not compressed, but the headers was already added to indicate compression. I think we've resolved the instances of that bug, but it is reason to see if there are any errors recorded around that time. Unfortunately, TLS makes it hard to see the data stream from outside the application.

That's presuming that this problem is a case of web client setting the header but not compressing the body. The other main possibility is that there is a piece of network infrastructure that is modifying the stream in some way.

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

Sign in to reply to this post.