Summary: | [GTK] Azure portal login with Kerberos requires page reload | ||
---|---|---|---|
Product: | WebKit | Reporter: | brian |
Component: | WebKitGTK | Assignee: | Nobody <webkit-unassigned> |
Status: | RESOLVED MOVED | ||
Severity: | Major | CC: | bugs-noreply, mcatanzaro, phillip |
Priority: | P3 | Keywords: | Gtk |
Version: | WebKit Nightly Build | ||
Hardware: | PC | ||
OS: | Linux |
Description
brian
2022-02-18 04:50:05 PST
No warnings printed on the command line? This is gonna be tough to solve. Kerberos works fine for me across a variety of different websites, so it's got to be somehow specific to this particular page. No clue what could be the problem. :/ Would that be the evolution and/or epiphany commandline you are referring to, as in starting them from a shell prompt? But yes, do I agree, that "regular" Negotiate seems to work just fine. Epiphany can use a Kerberos ticket to authenticate to a GSSAPI-auth configured Apache server with no problems for example. It is interesting to note though, that in looking at all of HTTP transactions in the devtools in both Chrome and Epiphany when following the auth URL, that none of the Azure log in process is actually using the Negotiate authentication method, via HTTP authentication headers (that I can see at least). I don't know how it is working otherwise but it is. (In reply to brian from comment #2) > Would that be the evolution and/or epiphany commandline you are referring > to, as in starting them from a shell prompt? Yes. So, yes. On the first attempt where the webpage ends up asking for a password, epiphany emits a: (process:1656283): libsoup-WARNING **: 10:58:02.037: Failed to parse auth header But after hitting reload, where the second attempt works without asking for a password, no such message (or any message). OK great, that is https://gitlab.gnome.org/GNOME/libsoup/-/issues/184 and it's a libsoup bug. Now we're getting somewhere! Please, add your comments to the libsoup issue. Thanks. I'm going to close this as MOVED to the libsoup issue https://gitlab.gnome.org/GNOME/libsoup/-/issues/184. It seems to be a server problem, but if other clients are able to work around it, maybe libsoup can too. That's a layer below WebKit, though. |