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
>
>
--~--~---------~--~----~------------~-------~--~----~
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
-~----------~----~----~----~------~----~------~--~---

Reply via email to