Google Groups

Re: implementing a poco service provider: what if i can't infer who @me is?

Ryan B Feb 6, 2012 11:36 AM
Posted in group: PortableContacts
thanks for the info, guys!

the context is that i'm implementing unofficial "bridge" poco
providers for big players like facebook and twitter, similar to the
bridge webfinger providers i put up a bit ago:

in the first pass, i'm just making clients oauth with fb and twitter
directly, then give me their retrieved credentials, which i'll pass
through. fb supports "me" requests similar to poco, but at first it
looked like twitter didn't. i've since found the way in twitter,
though: /account/verify_credentials

so, all is well, back to hacking. thanks again. feel free to follow
along if you're bored!

the last two endpoints are visible but not fully functional yet. they
will be soon though!

On Mon, Feb 6, 2012 at 10:53 AM, Joseph Smarr <> wrote:
> You can always put a real userid in place of the @me in the URL--the @me is
> just a shorthand when the user is clear from the auth context. But can you
> say a bit more about why it's not clear in your case who the user it? Might
> point to a different underlying problem...
> On Mon, Feb 6, 2012 at 10:49 AM, Justin Richer <> wrote:
>> What we've done is standardize on URLs for different users and groups,
>> such as:
>>  http://profile-server/poco/username/
>> To get info for a particular user. We've got sub-URLs for different bits
>> of the heirarchy, such as everybody in a particular user's department:
>>  http://profile-server/poco/username/department/
>> PoCo doesn't really define what these query structures look like, so we
>> went with our own ontology. We're using both OAuth2 and OpenID for auth on
>> this server, we still do have mappings for "@me" in cases where we can look
>> up the user ID. For directly-connected clients that use 2-legged OAuth2, we
>> don't allow the "@me" queries.
>>  -- Justin
>> On 02/06/2012 01:41 PM, Ryan B wrote:
>>> hi all! i'm implementing a poco service provider that supports auth,
>>> but it can't use auth credentials alone to determine who the current
>>> logged in user (ie @me in poco) is. the poco spec kind of seems to
>>> require this, or at least doesn't explicitly talk about non-@me paths:
>>> it does allow extra query parameters, so i could require clients to
>>> pass in a user id or username as a query parameter, but i'd like to
>>> stick to the standard as close as possible so clients don't have to
>>> hard-code support for my provider. any thoughts?
>> --
>> You received this message because you are subscribed to the Google Groups
>> "PortableContacts" group.
>> To post to this group, send email to
>> To unsubscribe from this group, send email to
>> For more options, visit this group at