Re: Authenticate
- From: Dan Winship <danw gnome org>
- To: Daniel Morales <daniminas gmail com>
- Cc: libsoup-list gnome org
- Subject: Re: Authenticate
- Date: Fri, 20 Jul 2007 11:56:11 -0400
Daniel Morales wrote:
Hi @ all
I'm using the "authenticate" signal to login to some services... and all
works! :)..
My problem is because i need to change the user/passwd sometimes
(depending)..
Now i recive the 'authenticate' signal on the first request, and in the
next request(s) it uses the same user/passwd...
.. any idea to change the user/passwd or recive the auth signal again?
.. or something to solve this?
If the server rejects a password you gave it berfore, the session will
emit the "reauthenticate" signal, which works just like "authenticate",
but gives you a second chance.
This is a little confusing, but as explained in the API docs:
* An interactive application that doesn't cache passwords could
just connect both "authenticate" and "reauthenticate" to the
same signal handler, which would ask the user for a username and
password and then return that to soup. This handler would be
called repeatedly until the provided information worked, or
until it failed to return any information (eg, because the user
hit "Cancel" instead of "OK").
* A slightly cleverer interactive application would look in its
password cache from the "authenticate" handler, and return a
password from there if one was available. If no password was
cached, it would just call its "reauthenticate" handler to
prompt the user. The "reauthenticate" handler would first clear
any cached password for this host, auth type, and realm, then
ask the user as in the case above, and then store that
information in its cache before returning it to soup. (If the
password turns out to be incorrect, then "reauthenticate" will
be called again to force it to be uncached.)
* A non-interactive program that only has access to cached
passwords would only connect to "authenticate". If the username
and password that "authenticate" returns fail, the session will
emit "reauthenticate", but since the application is not
listening to that signal, no new username and password will be
returned there, so the message will be returned to the
application with a 401 or 407 status, which the application can
deal with as it needs to.
-- Dan
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]