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 <jsm...@gmail.com> 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 <jri...@mitre.org> 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: >>> >>> http://portablecontacts.net/draft-spec.html#anchor11 >>> >>> 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 portable...@googlegroups.com. >> To unsubscribe from this group, send email to >> portablecontac...@googlegroups.com. >> For more options, visit this group at >> http://groups.google.com/group/portablecontacts?hl=en. >> >