Pretty sure this is what Digg is ostensibly doing. Maybe Joe Stump can shed some light.
Chris On Wed, Apr 15, 2009 at 11:19 AM, pkeane <[email protected]> wrote: > > Great -- just what I was hoping to hear. I didn't want to start > implementing if there was a known deal-breaker that I was not seeing. > The caveats you mention, while important, are not deal breakers give > what we need. > > --peter > > On Apr 15, 12:48 am, Mike Malone <[email protected]> wrote: > > Yea, that would work, some caveats apply though. > > > > First, it sounds like you may not need all of OAuth, but if you want to > take > > advantage of the existing libraries and whatnot the extra OAuth features > > probably won't cause any problems. > > > > As you said, you'll want to generate signed OAuth URIs for the images on > > your server and insert them in your HTML. On the producer side (your > image > > server) you'll definitely want to check nonces -- if you don't then every > > URI you generate will continue working forever, and could be intercepted > by > > someone or forwarded to a third party. To limit the number of nonces you > > have to "remember" you might decide you'll only accept URIs with a > timestamp > > that's less than 24 hours old (for example), in which case you'll only > need > > to keep used nonces around for 24 hours. > > > > Even if you check nonces someone could still request the page, parse out > the > > URIs, and send them to a third party to use. So it's not perfect, but if > > you're currently using cookie-based auth it's probably about as secure as > > your existing solution. > > > > Mike > > > > On Tue, Apr 14, 2009 at 10:32 PM, pkeane <[email protected]> wrote: > > > > > I have been learning about OAuth a bit (I managed to access a GMail > > > inbox from GAE: > > >http://simplenotepad.appspot.com/text/goggle-app-engine-oauth-access-. > .. > > > ), > > > but I am still unclear on one point. Assuming I (i.e., the web app) > > > can get the access token, is it possible to construct a URL that can > > > be placed in an i...@src in the rendered html to allow the browser to > > > access a "restricted" image? > > > > > The use case is a digital image library (in heavy use at UT Austin) in > > > which some images are only available under "fair use." The "image > > > server" is a separate application from the rest of the app: we > > > currently check for a UT-specific secure cookie to serve restricted > > > images (lack of the cookie simply causes us to send a thumbnail > > > version). I'd much prefer a URL-based access scheme with a two-legged > > > OAuth approach. This piece need not be uber-secure -- we just don't > > > want to put all of the assets on the open web. > > > > > --peter keane > > > > > > > -- Chris Messina Citizen-Participant & Open Web Advocate factoryjoe.com // diso-project.org // vidoop.com This email is: [ ] bloggable [X] ask first [ ] private --~--~---------~--~----~------------~-------~--~----~ 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 -~----------~----~----~----~------~----~------~--~---
