On 07/22/2013 06:13 PM, Patrick Ohly wrote:
> The password was empty above. It could also be set by the user,
> expectation that the SSO backend then uses that instead of triggering
> any prompts.
No-one has commented on this part, right? It is needed for the use case
where SyncEvolution runs on a headless server (like the nightly testing,
or as SyncML<->WebDAV bridge).
I assume that this involves libsignon and signond. How can they be told
what username/password to use when dealing with OAuth2?
Here's the catch: in OAuth2 flows that are used by Google the clients
don't get to specify the username and password at all. It's managed
entirely by the server's user authentication endpoint that provides a
webpage that is opened in the browser: that webpage can either prompt
the user for the username/password, or use an existing session cookie to
skip the prompt and go straight to asking the user to confirm token
grant to a client (e.g. Google is reusing existing login sessions this way).
If you need entirely headless operation, Google supports something
called OAuth2 service accounts:
This feature is based on an IETF draft:
and as it's
a draft we've left it out of our initial OAuth implementation. Basic,
standardized OAuth2 is large enough by itself :)