GNOME Bugzilla – Bug 675306
async HTTP authentication is complicated, API-wise
Last modified: 2018-09-21 16:10:39 UTC
With current master, SoupSession auth manager fails to stop SoupMessages (epiphany:7004): libsoup-CRITICAL **: soup_session_pause_message: assertion `!item->new_api' failed Breakpoint 2, g_log (log_domain=0x7ffff4c0db65 "libsoup", log_level=G_LOG_LEVEL_CRITICAL, format=0x7ffff441d7a0 "%s: assertion `%s' failed") at gmessages.c:791 791 va_start (args, format); (gdb) bt
+ Trace 230170
Ah, it only fails if you're using SoupPasswordManager. The solution might be "finally kill off SoupPasswordManager" (qv bug 594377).
ohhhhh yeah, I never really liked that long #define :)
(In reply to comment #1) > Ah, it only fails if you're using SoupPasswordManager. The solution might be > "finally kill off SoupPasswordManager" (qv bug 594377). Well, just to clarify this comment, in the specific case of epy it will fail even when not using the SoupPasswordManager (for example running a private session "epiphany -p") but that's because webkitgtk+ GtkAuthenticationDialog tries to pause() the message when it's shown and unpause() it when the dialog is destroyed.
right, but that part can be fixed by using defersLoading instead of pause_message(). Pause was needed with the old SoupMessage API because otherwise the message would keep getting processed while you were asking for the password. But with the SoupRequest API, if you want the message to stop being processed, just stop reading from its stream.
(In reply to comment #4) > right, but that part can be fixed by using defersLoading instead of > pause_message(). Pause was needed with the old SoupMessage API because > otherwise the message would keep getting processed while you were asking for > the password. But with the SoupRequest API, if you want the message to stop > being processed, just stop reading from its stream. That'd indeed work but there is no way to access the ResourceHandle from that dialog AFAIK.
You can store a pointer to the ResourceHandle on the message. (In fact, we already do.) But anyway, it turns out that there's still a problem; defersLoading will have no effect until soup_request_send_async() returns, but by the time that returns, it's too late (libsoup has already failed the request). I am pondering this. (Short-term solution will probably be to make pause/unpause work up until send_async() returns. Longer-term solution may involve reorganizing how authentication works.)
soup_session_pause_message() is now re-enabled for this case
(In reply to comment #7) > soup_session_pause_message() is now re-enabled for this case Authentication seems to work again with that change but I'm getting this whenever a new download is triggered by webkitgtk (GtkLauncher:13666): libsoup-CRITICAL **: soup_message_io_pause: assertion `io->read_state < SOUP_MESSAGE_IO_STATE_BODY' failed (gdb) bt
+ Trace 230192
(In reply to comment #6) > But anyway, it turns out that there's still a problem; defersLoading will have > no effect until soup_request_send_async() returns, but by the time that > returns, it's too late (libsoup has already failed the request). > > I am pondering this. (Short-term solution will probably be to make > pause/unpause work up until send_async() returns. Longer-term solution may > involve reorganizing how authentication works.) Figured out what I'm going to do here: soup_request_send() will just return an error, and you can call soup_request_get_auth() or something to get the pending auth, eventually call soup_auth_authenticate() on it, and then soup_request_send() the request again.
[mass-moving all "UNCONFIRMED" libsoup bugs to "NEW" after disabling the "UNCONFIRMED" status for this product now that bugzilla.gnome.org allows that. bugspam-libsoup-20150210]
Is this bug obsolete...? The title is surely wrong: "HTTP authentication broken" is definitely not generally true.
The part that's still valid is that async authentication handling requires connecting to signals and calling soup_session_pause_message() at the right time, etc. Ideally there'd be a simpler way (as in comment 9)
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/libsoup/issues/43.