logo       

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

web.flickr.api

Subject: Re: [Flickr APIs] new authentication api

On 21/8/04 12:45 am, Cal Henderson wrote:

> the url we'd store would be the return url with the query
> string chopped off.
>
> a call from:
> www.a.com/blog_login.cgi?post_id=11
> would have the same url as:
> www.a.com/blog_login.cgi?post_id=12
>
> if you used an open source weblogging app as in this example,
> flickr would prompt the user for each different weblog they
> wanted to authenticate against. this seems correct behavoir,
> since they are in a sense 'different applications'.


This does appear to solve the issue. It might be good to support an array as
per Peter notes TypeKey does. It may not be a widespread setup but I use
multiple domains with my site. The return URL could then be matched minus
its query string against any of the URLs registered for that api_key.

For non user installed application setups as employed by many 'services'
(e.g. like Blogger) it would also be more flexible if the stored URL
supported a wildcard. - Thus allowing login URLs where the login script is
within a user specific part of the URL (e.g. *.example.com/login? or
example.com/*/login? -the asterisk representing the username). This would be
registered on a per-service basis and not per-user but the user in this case
would be authenticating against the entire service.

I realise that wildcards would not be required if the service just used a
centralised login script and simply redirected using a user argument passed
in the return URL, but I don't think that's such a clean solution as Flickr
returning the user directly to where they should be. This is of course all
subjective and dependant upon where you think your API could/should be
used...


// Jacob





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

News | FAQ | advertise