Oh. I have as a task on my list also supporting the signature signed with the 'full' subdomain (http://api123.photobucket.com) as well, for the repeat-signing situation, if deemed necessary. I'd likely have the consumer specify that number in the parameter list (shard hint as below) for completeness so I know to try that method first. It may prove to be the better implementation, but it hasn't been a major complaint yet.
On Dec 1, 6:07 pm, Brian Eaton <[EMAIL PROTECTED]> wrote: > On Mon, Dec 1, 2008 at 4:40 PM, Justin Hart <[EMAIL PROTECTED]> wrote: > > We have run into and come up with a specific solution this problem on > > Photobucket, since we require photo album operations to happen on the > > appropriate 'silo' the user is on (our sharding technique). > > NetFlix, Y!, and Google Calendar all have similar behaviors > implemented in slightly different ways. Is there a best practice in > this area? > > NetFlix and Yahoo: return a unique id for the user along with the > access token. Clients must include this unique id in the URLs of > subsequent requests. > > Google Calendar: include a shard hint both in a URL query parameter > and a cookie. If both are missing, redirect and set the cookie. > > And now photobucket: redirect each request to a different hostname, > and expect the client to resend the request with the original > hostname. (Justin, have I got this right? Photobucket wants a > request forhttp://api123.photobucket.com/to be signed as if it were > forhttp://api.photobucket.com?) --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~----------~----~----~----~------~----~------~--~---
