Re: Authenticate



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]