It's also similar to the way Amazon S3 URIs work, except with S3 the timestamp is actually the expiration date for the URI (as opposed to the time that the request was created) and there's no nonce (URIs can be used repeatedly until they expire). You may want to take a look at their API for some more ideas / to validate your own ideas.
Mike On Wed, Apr 15, 2009 at 11:25 AM, Chris Messina <[email protected]>wrote: > 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 -~----------~----~----~----~------~----~------~--~---
