logo       

Re: [Flickr APIs] new authentication api: msg#00051

web.flickr.api

Subject: Re: [Flickr APIs] new authentication api

Jacob Jay <jacob-w1M1GQjzACPYtjvyW6yDsg@xxxxxxxxxxxxxxxx> wrote:
: I'm rather confused by how this idea would work. When would the mask be
: passed, and why would it not be possible to simply 'hijack' that too,
unless
: it is only passed on one occasion?

it would be passed every time. let me try and explain.

in the vanilla version, when a user is sent to flickr
to authenticate, it makes a hash of their user id, the
api key and the return url. if this hash doesn't
already exist in our auth database then the user is
prompted to see if they want to let the application
authenticate them, before anything is passed back to
the app. we then store the hash in our database.

the upshot is that *every user* must seperately choose
to allow to be authenticated against *every api key*
using *every return url*. this shifts the responsibility
of choosing what to authenticate against to the user.

the downside of this approach is that if i develop an
app which uses several return urls (e.g. typepad, etc)
then a single user will have to authenticate multiple
times, once for each return url that is used by the
application.

to avoid this, with each auth call, an application can
send along a mask of possible return urls that it will
use. so typepad sends a mask of auth.typepad.com/*
to say that any time this user, using this api key, is
sent back to a url within this mask, the url is to be
thought of as the 'same' as any other in this mask.

for a distributed application, the return mask would
be limited to just that installation (because we don't
allow masks more specific that *.domain.tld/*), so the
user is only asked whether they trust that particular
installation, rather than all installations.

does that make any sense?


--cal




<Prev in Thread] Current Thread [Next in Thread>
Google Custom Search

News | FAQ | advertise