Re: [Flickr APIs] new authentication api

On 24/8/04 7:49 pm, Cal Henderson wrote:

> return_url=http://www.foo.com/users/cal/auth
> &return_mask=http://www.foo.com/users/*/auth

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?

Without intimate knowledge of your architecture and intentions I'm thinking
thusly...

Every instance of an application should register itself to avoid the hole in
user privacy. That registration process would attach the url mask to an
api_key. Thus an application product (user installed), or application
service (provider hosted) would have to, upon installation/creation,
register itself with your api_key table.

I imagine you want to avoid manually registering multitudes of
user-installations of a particular product. This procedure should therefore
be automated, -which is no more a risk than from borrowed/hijacked api_keys.

In an automated registration system a simple call like
http://www.flickr.com/services/auth/?action=register&return_url={return_url}
&return_mask=example.com/users/*/auth would return an api_key for exclusive
use by a product installation, and against which users would authorise any
[return_]url associated with that key's mask... (probably worth adding a
product_id to that registration call for your stats)

A simpler solution than this (albeit not as secure) could be to restrict
api_key calls/returns to an originating IP determined automatically from the
first call. The few applications requiring CIDR/subnet matching could be
setup manually.

// Jacob