Erik Rull wrote: > Erik Rull wrote: >> Stefano Crocco wrote: >>> On sabato 30 gennaio 2021 09:25:45 CET Erik Rull wrote: >>>> Stefano Crocco wrote: >>>>> On giovedì 28 gennaio 2021 23:39:00 CET Erik Rull wrote: >>>>>> Stefano Crocco wrote: >>>>>>> On martedì 26 gennaio 2021 22:04:15 CET Erik Rull wrote: >>>>>>>> Hi all, >>>>>>>> >>>>>>>> I don't know how to get this working again. I just updated to 20.04 >>>>>>>> from >>>>>>>> 16.04 (kubuntu LTS) and before the update this was working great: >>>>>>>> >>>>>>>> I start my Linux box (just power on) and remote SSH into the system >>>>>>>> (X-Forwarding enabled). Then I open my applications and also konqueror. >>>>>>>> This works all fine and smoothly, websites are displayed fine. Until I >>>>>>>> try to access a website with HTTP-Authentication - there I directly get >>>>>>>> a 401 - no asking for a password, nothing, just the 401 page directly. >>>>>>>> Firefox prompts me for the username/password and shows me the page >>>>>>>> behind the >>>>>>>> authentication. So the server is fine. I tried multiple servers and >>>>>>>> konqueror behaves always the same. >>>>>>>> >>>>>>>> Any idea what I broke during the update? >>>>>>>> >>>>>>>> Best regards, >>>>>>>> >>>>>>>> Erik >>>>>>> >>>>>>> Hello Erik, >>>>>>> do you by any chance know whether your previous version of Konqueror >>>>>>> still >>>>>>> used the WebKit engine or had it already switched to QtWebEngine? In the >>>>>>> first case, I think you can have found yet another feature which stopped >>>>>>> working with the switch to the new engine. >>>>>>> >>>>>>> If your current Kubuntu version still provides KWebKitPart, you could >>>>>>> also >>>>>>> try installing it, select it as default web engine in the General tab of >>>>>>> the Konqueror settings page and check whether the HTTP Authentication >>>>>>> works with it. If it does, the problem lies with QtWebEngine, otherwise, >>>>>>> we'll need to investigate somewhere else. >>>>>>> >>>>>>> Stefano >>>>>> >>>>>> Hi Stefano, >>>>>> >>>>>> I don't know exactly. How can I check this and / or switch the engine? >>>>>> When opening konqueror and access e.g. google.com then a new process is >>>>>> listed with QtWebEngineProcess - so I assume this is the QtWebEngine. >>>>>> I tried to search for kwebkit in aptitude - nothing found... >>>>>> Maybe it is hidden in a different named package? >>>>>> >>>>>> Best regards, >>>>>> >>>>>> Erik >>>>> >>>>> Hello Erik, >>>>> the current version of Konqueror uses QtWebEngine by default. I fear that >>>>> kwebkitpart may have been removed from it (for instance, I know it's been >>>>> removed from Gentoo). In the weekend, I'll try to install an Ubuntu >>>>> virtual >>>>> machine with both Ubuntu 20.04 and 16.04 to check what the situation is. >>>>> >>>>> Stefano >>>> >>>> Hi Stefano, >>>> >>>> >>>> Thanks a lot! >>>> Please try the SSH access before you logged in. >>>> >>>> I found out something new meanwhile: >>>> When NOT logging in directly on the desktop - I get the 401 with konqueror >>>> directly via SSH - that I described already. >>>> BUT - When logging into the system directly (local screen and keyboard) and >>>> THEN open the konqueror remotely via SSH, konqueror does NOT display the >>>> 401 - it "waits". But what happens in parallel on the local screen: the >>>> authentication dialog of the requested website pops up! >>>> >>>> So "something" is different when being logged in directly. But the behavior >>>> is still odd, because you have no chance to access the login dialog via >>>> SSH... >>>> >>>> Any ideas? >>>> >>>> Best regards, >>>> >>>> Erik >>> >>> Hello Erik, >>> I can confirm that, unfortunately, KUbuntu 20.4 doesn't include >>> KWebKitPart. If >>> you are comfortable building programs from source, you can download it from >>> https://invent.kde.org/libraries/kwebkitpart and install it (it requires >>> kdewebkit which is available in KUbuntu). After installing it, in the >>> General >>> tab of Konqueror settings dialog, you'll be able to set KWebKit as default >>> web >>> browser engine. I'm not sure whether this will fix your issue or not, >>> however. >>> >>> As I've never used ssh with X-forwarding, could you please explain step by >>> step what you did to in the two situations you described? I tried setting >>> up a >>> very minimalistic server with http authentication and accessing it with >>> using >>> Konqueror from ssh and I had no problems neither with the old KWebKit nor >>> with >>> the new QtWebEngine. >>> >>> Stefano >> >> Hi Stefano, >> >> sure - her a bit more verbose what I did (target system is kubuntu 20.04): >> - install the SSH server on the target system >> - do a fresh boot of the target system (just power it up) >> - start an SSH client on an second system or use konsole on the second >> system with: >> ssh -X user@target >> (enter password) >> then on the new opened remote console: >> konqueror >> Enter a URL that requires username/password via HTTP >> Now there are two possibilities: >> 1) you have NOT logged in on the target desktop via keyboard / monitor >> => you get a 401 directly >> 2) you have logged on the target desktop when calling the URL >> => you get a "busy" icon on the upper right but no dialog via SSH >> => you get the dialog prompted on the desktop of the target desktop >> => nothing happens on your remote session, you can press ESC to proceed >> browsing to somewhere else but the dialog stays open on the target desktop >> >> Best regards, >> >> Erik > > Hi Stefano, > > I tried a bit more - I tried to use another browser using the QTWebEngine and > I > found "falkon" in the repositories. > And this browser worked just fine - I got the http login dialog from both SSH > remote and locally. > So the chance that the QTWebEngine is the root cause got less likely. > I checked what happens in addition compared to the falkon browser and > discovered > the dbus session. > I have a bad feeling that the dbus / dbus-session might be the troublemaker... > > Best regards, > > Erik
Found it! it is necessary to issue a: export $(dbus-launch) after the login to get the login dialogs! Otherwise this will not work. Best regards, Erik
