GNOME Bugzilla – Bug 789749
Epiphany does not run Citrix apps
Last modified: 2017-11-05 03:23:51 UTC
Connecting to Citrix server, Epiphany doesn't run apps. Clicking on app icon, a small timer spins a couple of times at the bottom of the icon, then stops. Nothing is downloaded or run. No problem with Firefox. Have not yet tried another WebKit2 browser.
Launcher.ica file does not download.
Tested Qupzilla and works correctly. Problem appears to be with Epiphany rather than WebKit.
Citrix requires use of NPAPI plugins so it'll probably be something related to that. If the plugins are expected to draw anything, that's supported only under X11 and has no chance of working under Wayland. Same comment here as for your previous bug: QupZilla is not an appropriate comparison (it doesn't even support NPAPI, I bet Citrix does something completely different for Chromium), and it's unlikely that anybody will debug this for you unless the Citrix developers have some comment about why it doesn't work. Thanks for taking the time to report this. This issue is most likely a bug in WebKit. Please report the bug to https://bugs.webkit.org/ including a link to this bug report and noting the version of WebKitGTK+ that you have installed. When reporting the WebKit bug, be sure to include the prefix '[GTK]' in the bug summary and select the 'WebKit Gtk' component.
(In reply to Michael Catanzaro from comment #3) > This issue is most likely a bug in WebKit. Well, 50% chance it could be Citrix's fault; I have no clue. ;)
Clicking on app icon should download launcher.ica file. It doesn't matter if plugin is installed or not. File should download.
Please post an example URL that demonstrates the problem.
I was given the problem by someone who lent me her work account to test. It's a government agency, so I'm not at liberty to give it out. I can try to get permission, but, being a government agency, it may take some time. They didn't approve me right away :-) Is there anyone else who could lend you there account?
Tested Surf-2 and MiniBrowser - neither downloaded the launcher.
OK, so NOTGNOME then... but one more thing to check. Look in the web inspector; there might be an error there. I should have asked you to do that first.
Also: if you are ever able to post a URL that we can use to reproduce the problem, feel free to report on WebKit Bugzilla. Make sure to select the WebKitGTK+ component when reporting.
Created attachment 362859 [details] Screenshot of Surf-2 Web Inspector
Did you attach the wrong screenshot? That looks like the output of curl running in a terminal. If that's the right screenshot, then surf must be downloading everything manually instead of using WebKit's network stack (WebKitGTK+ uses libsoup, not curl). That would be pretty wild, but would also explain the weird results you found in bug #789735.
I saved a screenshot of the Surf-2 popup window with Web Inspector enabled. It indicates a problem with certificates, though it doesn't say which one. I am using the full set of certificates taken from Firefox. Is there a way to disable verification of certificates in Epiphany? Looking at the Web Inspector screen, the console doesn't show any errors, warnings or log entries. What do you suggest?
Yes, that's the correct screenshot. And they do appear to be downloading manually through curl instead of WebKit. Wild, but maybe with good reason? It could explain why Surf works with SquirrelMail when Epiphany and MiniBrowser fail. Maybe WebKit loses or forgets to refer to the cookie? The problem with Citrix may be that only the first certificate is being loaded. The next certificate isn't being loaded or the user notified. The script simply exits without doing anything.
Here's the source code for surf: https://git.suckless.org/surf/tree/surf.c I don't see any use of curl there. I'm very confused. Anyway. (In reply to Technical Support from comment #13) > I saved a screenshot of the Surf-2 popup window with Web Inspector enabled. > It indicates a problem with certificates, though it doesn't say which one. I > am using the full set of certificates taken from Firefox. > > Is there a way to disable verification of certificates in Epiphany? Not completely... you can disable it for a particular domain by clicking through Technical Information -> Accept Risk and Proceed, but if the page loads subresources from other domains, those will still be blocked and there's no way to avoid that except by modifying the source code. I see surf has a StrictTLS property you can use (see config.def.h). I'm not sure how to change it, though, and it's not going to affect downloads (see below). > Looking at the Web Inspector screen, the console doesn't show any errors, > warnings or log entries. What do you suggest? It shows (1) that a resource has been blocked due to an unacceptable TLS certificate and (2) that surf is not even using WebKit's network stack. Both curl and libsoup are going to be much less forgiving about questionable certificate chains than major browsers. To see why it was *probably* rejected (it's not currently possible to know for sure), you can use gnutls-cli which *almost* always gives the same result as glib-networking (the component that's doing the actual certificate verification, using GnuTLS). Anyway, that probably explains why the download is failing... but I thought there should be an error in the web inspector. Maybe it's not printed for downloads. Aaaand here's the answer, in config.def.h: /* DOWNLOAD(URI, referer) */ #define DOWNLOAD(u, r) { \ .v = (const char *[]){ "st", "-e", "/bin/sh", "-c",\ "curl -g -L -J -O -A \"$1\" -b \"$2\" -c \"$2\"" \ " -e \"$3\" \"$4\"; read", \ "surf-download", useragent, cookiefile, r, u, NULL \ } \ } So surf uses curl instead of WebKitDownload. No clue why. It looks like it also uses mpv instead of WebKit to play the videos. Wow!
Interesting :-) I copied all the certificates from Firefox but still the certificate verification fails. I wonder what is going wrong? You seem to be saying that there is no way to tell Epiphany to accept certificates without verification. Except the first of a series of certificates, which isn't necessary since it's verifying correctly from what I saved. I am saving certificates in /usr/local/share/ca-certificates and running update-ca-certificates. This method seems to satisfy Epiphany. Maybe the problem is that subsequent certificates are matched against the first certificate? Is there a way to see what certificate is failing? Is there a way to save it better? If there's a bug, how do we go about getting it fixed? I would like to see people switch from Chrome and Firefox to Epiphany :-)
Created attachment 362865 [details] Problem not with certificate Okay, certificates not a problem. I ran update-ca-certificates again and problem went away. Now this (attached) is what Surf-2 displays. Epiphany is getting a little further also. Progress bar moves most way then script stops. Launcher.ica does not download. Any ideas?
(In reply to Technical Support from comment #16) > Interesting :-) > > I copied all the certificates from Firefox but still the certificate > verification fails. I wonder what is going wrong? > > You seem to be saying that there is no way to tell Epiphany to accept > certificates without verification. Except the first of a series of > certificates, which isn't necessary since it's verifying correctly from what > I saved. I am saving certificates in /usr/local/share/ca-certificates and > running update-ca-certificates. This method seems to satisfy Epiphany. Maybe > the problem is that subsequent certificates are matched against the first > certificate? No, the entire chain gets verified together. But you can tell WebKit to accept a particular certificate for a particular domain. Epiphany lets you do that if the main resource has an invalid certificate, but not for subresources: those get silently blocked. The reason for that is simple: that's the same as what Chrome, Firefox, and IE/Edge all do. Safari actually warns about problems with subresource certificates and lets you bypass those errors too, but that confuses users, and there are security implications. > Is there a way to see what certificate is failing? Is there a way to save it > better? If there's a bug, how do we go about getting it fixed? > > I would like to see people switch from Chrome and Firefox to Epiphany :-) In Epiphany, you *should* see an error in the web inspector: that will let you know which resource was rejected. (I know you don't see the error. Maybe it's broken for downloads, or maybe we're wrong and it's not a certificate problem.) Then you can use gnutls-cli to see why it's rejecting the certificate chain (which almost always works: there can be verification failures introduced due to GNOME bugs as well, but that's unlikely here). If you post the output of gnutls-cli, then I can look and make a guess as to what's wrong, but the most common problem I see nowadays is the server sends only a single certificate in the chain, without any intermediate certificate. Firefox works around such problems by caching intermediates you've seen before, so successful verification depends on your browser history. Chrome just downloads them automatically, which Firefox refuses to do because then verification becomes a supercookie: it allows CAs to track you across the internet. That's what I was planning to implement for Epiphany, but it's a real problem....
The Control Panel in Web Inspector stops showing anything once Citrix logs in. From there, there's no indication of what's causing trouble. Fortunately, we're fine on certificates now. The problem was fixed by reinstalling the two, I believe, certificates required. (The second one seemed to have installed badly.) It would be nice to be able to see exactly what's failing as it happens. When a certificate fails verification, it would help to know which one. The certificate has been fixed. It would help to see what is failing. In comment #17 I attached a screenshot of the new problem as reported by Surf-2. Something to do with not being able to save the downloaded file. Could this be the problem with Epiphany too? Why would there be a problem saving when other downloads work fine? As for avoiding the supercookie problem, bravo! Convenience is good but not at the expense of people secretly being tracked.
(In reply to Technical Support from comment #19) > In comment #17 I attached a screenshot of the new problem as reported by > Surf-2. Something to do with not being able to save the downloaded file. > Could this be the problem with Epiphany too? Why would there be a problem > saving when other downloads work fine? No clue.
The filename to be saved is "launcher.ica". Maybe the entire string (including everything following the ? mark) is being used for the filename? The download isn't even being attempted, so maybe something sees that the filename is too long? Or maybe it's something else entirely :-)
Anyway, it's moved to WebKit Bugzilla now.