Top |
SoupAuthManager is the SoupSessionFeature that handles HTTP authentication for a SoupSession.
A SoupAuthManager is added to the session by default, and normally
you don't need to worry about it at all. However, if you want to
disable HTTP authentication, you can remove the feature from the
session with soup_session_remove_feature_by_type()
, or disable it on
individual requests with soup_message_disable_feature()
.
#define SOUP_TYPE_AUTH_MANAGER (soup_auth_manager_get_type ())
The GType of SoupAuthManager; you can use this with
soup_session_remove_feature_by_type()
or
soup_message_disable_feature()
.
(Although this type has only been publicly visible since libsoup
2.42, it has always existed in the background, and you can use
to get its GType in earlier releases.)g_type_from_name ("SoupAuthManager")
Since 2.42
void soup_auth_manager_use_auth (SoupAuthManager *manager
,SoupURI *uri
,SoupAuth *auth
);
Records that auth
is to be used under uri
, as though a
WWW-Authenticate header had been received at that URI. This can be
used to "preload" manager
's auth cache, to avoid an extra HTTP
round trip in the case where you know ahead of time that a 401
response will be returned.
This is only useful for authentication types where the initial Authorization header does not depend on any additional information from the server. (Eg, Basic or NTLM, but not Digest.)
Since 2.42
“authenticate”
signalvoid user_function (SoupAuthManager *manager, SoupMessage *msg, SoupAuth *auth, gboolean retrying, gpointer user_data)
Emitted when the manager requires the application to provide authentication credentials.
SoupSession connects to this signal and emits its own “authenticate” signal when it is emitted, so you shouldn't need to use this signal directly.
manager |
the SoupAuthManager |
|
msg |
the SoupMessage being sent |
|
auth |
the SoupAuth to authenticate |
|
retrying |
|
|
user_data |
user data set when the signal handler was connected. |
Flags: Run First