[oauth] Re: authorized access by url alone?
If you want to use standard OAuth libraries, use a full set of credentials: consumer key and consumer secret, token and token secret. It's more than you need, but some libraries require it all. If you need help using a specific library, this is a pretty good place to ask. On Apr 14, 10:32 pm, pkeane wrote: > 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? --~--~-~--~~~---~--~~ You received this message because you are subscribed to the Google Groups "OAuth" group. To post to this group, send email to oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: authorized access by url alone?
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 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 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 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 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: authorized access by url alone?
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 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 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 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: authorized access by url alone?
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 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 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
[oauth] Re: authorized access by url alone?
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 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-to-gmail > ), > 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 oauth@googlegroups.com To unsubscribe from this group, send email to oauth+unsubscr...@googlegroups.com For more options, visit this group at http://groups.google.com/group/oauth?hl=en -~--~~~~--~~--~--~---
