On martedì 2 febbraio 2021 20:09:25 CET Erik Rull wrote: > 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
Hello Erik, I'm happy you solved your problem. I'm sorry I couldn't help you more, but I've been very busy with work and I didn't have time to investigate. Stefano
