DeskApp 1.7 - net:ERR_FAILED Bug (including solution)

Harti

I just identified an issue with profiles in the DeskApp (causing net:ERR_FAILED to occur).

The web server URL is being trimmed from e.g. “https://” to “//” (which usually checks by itself whether the service has SSL enabled, so it’s common practice) after saving the profile.

This causes authentication to fail once you’re trying to sign in, because the application tries sending an XHR to “chrome://example.com/webapp/” instead of “//example.com/webapp/”. I’m assuming XHRs do not default to the automatic SSL lookup behavior and need their protocol to work.

Hence, the whole code in modules/WebAppWindow.js is erroneous. I could not identify where exactly the “https:” part is being omitted, but created a function to sanitize this.profile.requestOptions.url that is being called whenever that variable is being referenced.

Your engineers might want to look into hotfixing this.
See this gist as a guide.

-Harti

bjoernneumann

Hi Harti,

thank you very much for your findings and the solution.

I’d like to find the root cause for that. Are you able to reproduce this issue?

Cheers, Björn

Harti

I don’t know what environments you’re using, and what you suggest “the issue” is - however this issue is reproducible for our whole office.

I believe the issue is the part where it saves your profile configuration and trims the “https:” from the URL. I haven’t investigated what kind of XHR calls you are making when saving the config, but it should be easy to find out for your software developers why the string value is getting converted.
Usually, when a user specifies that their Kopano WebApp address is HTTPS, it’s fair to assume that the user wanted to put HTTPS and not the “take whichever protocol” wildcard ("//"). It’s also very unlikely that a HTTPS service ever changes to HTTP only.

As for the “//” causing a lookup issue, this could theoretically be due to Windows 10 Pro or our DNS doing weird things, but I doubt that this should be resolved on our end.

bjoernneumann

@Harti
We never had such an issue in our environments.
But sure, looks like a protocol-relative URL.

Maybe the Location header returned by the webserver looks like that.
Could you check what the webserver returns in “Location:”?

Harti

@bjoernneumann said in DeskApp 1.7 - net:ERR_FAILED Bug (including solution):

Maybe the Location header returned by the webserver looks like that.
Could you check what the webserver returns in “Location:”?

You’re correct, that returned the protocol relative URL starting with “//”.

I think it’s running behind a proxy but I’m not the sysadmin so take this information with a grain of salt.

bjoernneumann

@Harti
Thanks for checking.
I’ve created https://jira.kopano.io/browse/KD-363

Harti

@bjoernneumann
I had our sysadmin check/fix the Location header, DevTools now return “https://”, but the result stays the same unfortunately (even after deleting and re-creating a profile).
Thanks for creating the bug report.

bjoernneumann

@Harti
Created a fix for this. As we cannot reproduce this internally, would it be possible for you to test it?

~~https://stash.kopano.io/projects/KD/repos/kopano-deskapp/commits/f0ab20481f5bebea986d7acf7091f9018661cbba~~
https://stash.kopano.io/projects/KD/repos/kopano-deskapp/commits/59e762d4f34fd1bed72c66374a1ab4489842822b