Re: Trouble with konqueror on http authentication
Stefano Crocco <[email protected]> Tue, 02 Feb 2021 20:42:23 +0100
| Newsgroups | gmane.comp.kde.linux |
|---|---|
| Message-ID | <1702454.TLkxdtWsSY@linux> |
On marted=EC 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=EC 28 gennaio 2021 23:39:00 CET Erik Rull wrote: > >>>>>> Stefano Crocco wrote: > >>>>>>> On marted=EC 26 gennaio 2021 22:04:15 CET Erik Rull wrote: > >>>>>>>> Hi all, > >>>>>>>>=20 > >>>>>>>> I don't know how to get this working again. I just updated to 20= =2E04 > >>>>>>>> from > >>>>>>>> 16.04 (kubuntu LTS) and before the update this was working great: > >>>>>>>>=20 > >>>>>>>> I start my Linux box (just power on) and remote SSH into the sys= tem > >>>>>>>> (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 direc= tly > >>>>>>>> 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 pa= ge > >>>>>>>> behind the > >>>>>>>> authentication. So the server is fine. I tried multiple servers = and > >>>>>>>> konqueror behaves always the same. > >>>>>>>>=20 > >>>>>>>> Any idea what I broke during the update? > >>>>>>>>=20 > >>>>>>>> Best regards, > >>>>>>>>=20 > >>>>>>>> Erik > >>>>>>>=20 > >>>>>>> Hello Erik, > >>>>>>> do you by any chance know whether your previous version of Konque= ror > >>>>>>> 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. > >>>>>>>=20 > >>>>>>> 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. > >>>>>>>=20 > >>>>>>> Stefano > >>>>>>=20 > >>>>>> Hi Stefano, > >>>>>>=20 > >>>>>> 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 proce= ss > >>>>>> is > >>>>>> listed with QtWebEngineProcess - so I assume this is the QtWebEngi= ne. > >>>>>> I tried to search for kwebkit in aptitude - nothing found... > >>>>>> Maybe it is hidden in a different named package? > >>>>>>=20 > >>>>>> Best regards, > >>>>>>=20 > >>>>>> Erik > >>>>>=20 > >>>>> 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. > >>>>>=20 > >>>>> Stefano > >>>>=20 > >>>> Hi Stefano, > >>>>=20 > >>>>=20 > >>>> Thanks a lot! > >>>> Please try the SSH access before you logged in. > >>>>=20 > >>>> 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 keyboa= rd) > >>>> 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! > >>>>=20 > >>>> 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... > >>>>=20 > >>>> Any ideas? > >>>>=20 > >>>> Best regards, > >>>>=20 > >>>> Erik > >>>=20 > >>> 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). Aft= er > >>> 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. > >>>=20 > >>> As I've never used ssh with X-forwarding, could you please explain st= ep > >>> 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. > >>>=20 > >>> Stefano > >>=20 > >> Hi Stefano, > >>=20 > >> 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 > >>=20 > >> =3D> you get a 401 directly > >>=20 > >> 2) you have logged on the target desktop when calling the URL > >>=20 > >> =3D> you get a "busy" icon on the upper right but no dialog via SSH > >> =3D> you get the dialog prompted on the desktop of the target desktop > >> =3D> nothing happens on your remote session, you can press ESC to pro= ceed > >>=20 > >> browsing to somewhere else but the dialog stays open on the target > >> desktop > >>=20 > >> Best regards, > >>=20 > >> Erik > >=20 > > Hi Stefano, > >=20 > > I tried a bit more - I tried to use another browser using the QTWebEngi= ne > > and I found "falkon" in the repositories. > > And this browser worked just fine - I got the http login dialog from bo= th > > 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... > >=20 > > Best regards, > >=20 > > Erik >=20 > Found it! > it is necessary to issue a: > export $(dbus-launch) > after the login to get the login dialogs! >=20 > Otherwise this will not work. >=20 > Best regards, >=20 > Erik Hello Erik, I'm happy you solved your problem. I'm sorry I couldn't help you more, but= =20 I've been very busy with work and I didn't have time to investigate. Stefano