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