After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 653339 - Add authentication API
Add authentication API
Status: RESOLVED WONTFIX
Product: folks
Classification: Platform
Component: libfolks
git master
Other All
: Normal enhancement
: Future
Assigned To: folks-maint
folks-maint
Depends on:
Blocks:
 
 
Reported: 2011-06-24 13:59 UTC by Philip Withnall
Modified: 2012-06-12 17:40 UTC
See Also:
GNOME target: ---
GNOME version: ---



Description Philip Withnall 2011-06-24 13:59:41 UTC
As discussed with Matthew Barnes, folks needs to support passing authentication data through to at least some of the e-d-s PersonaStores.

Presumably this data will normally come from gnome-keyring, but I'm undecided about whether the gnome-keyring dependency should be in folks, or in the applications using folks. I suspect the latter, with the authentication API in folks being a thin abstraction layer around the possible authentication requests from folks' backends.
Comment 1 Travis Reitter 2011-08-01 18:39:17 UTC
Punting bugs that won't be fixed by Folks 0.6.0.
Comment 2 Travis Reitter 2011-09-20 00:07:24 UTC
How does this work currently for, eg, a Google contacts account in e-d-s?

I thought the authentication was all done transparently behind our backs (like it is for the Telepathy PersonaStores).
Comment 3 Philip Withnall 2011-09-20 07:13:42 UTC
(In reply to comment #2)
> How does this work currently for, eg, a Google contacts account in e-d-s?

If the user has GOA installed and set up for that account: Everything works fine.
Otherwise, if the user has previously opened Evolution this session and authenticated the account (and e-addressbook-factory hasn't died in the meantime): Everything works fine.
Otherwise, if the user has not used Evolution to authenticate the account in e-addressbook-factory: libfolks needs to authenticate it.

Question which has just come to mind: What if folks is the only Tp client currently running, and the user has a Tp account which is configured to not “remember password”? Will Telepathy spawn a password dialogue itself, or will things just fail? In the latter case, we'd have to handle authentication ourselves as with EDS.
Comment 4 Travis Reitter 2011-09-27 23:40:07 UTC
(In reply to comment #3)
> (In reply to comment #2)
> > How does this work currently for, eg, a Google contacts account in e-d-s?
> 
> If the user has GOA installed and set up for that account: Everything works
> fine.
> Otherwise, if the user has previously opened Evolution this session and
> authenticated the account (and e-addressbook-factory hasn't died in the
> meantime): Everything works fine.
> Otherwise, if the user has not used Evolution to authenticate the account in
> e-addressbook-factory: libfolks needs to authenticate it.
> 
> Question which has just come to mind: What if folks is the only Tp client
> currently running, and the user has a Tp account which is configured to not
> “remember password”? Will Telepathy spawn a password dialogue itself, or will
> things just fail? In the latter case, we'd have to handle authentication
> ourselves as with EDS.

If Empathy is installed, empathy-auth-client should be launched by D-Bus activation. Failing that, we could handle it through Channel.Interface.SASLAuthentication: 
http://telepathy.freedesktop.org/spec/Channel_Interface_SASL_Authentication.html

(which I'm sure empathy-auth-client is a good example of).
Comment 5 Jeremy Whiting 2012-06-12 16:38:16 UTC
Evolution-data-server handles authentication for us now, so closing this bug.