[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 -~--~~~~--~~--~--~---
[oauth] authorized access by url alone?
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 -~--~~~~--~~--~--~---
[oauth] Re: OAuth for installed apps
Not that I have a solution, but I just wanted to point out that your criticism of OAuth basically holds for just about all forms of client-side token solutions in some form or another. Folks like Adobe and Microsoft have invested a lot in DRM to try to solve this problem, but if there's motivation, nothing is really 100% secure — or 100% scalable. The question is whether OAuth makes things better — and I think, generally it does. For a different take on your point, at least in the desktop case, your credentials can't be sold unless you sell the containing computer (see Twollow, for sale on Sitepoint for $1000, including its database with Twitter credentials: http://tr.im/twollow). Lastly, for an example of someone who's doing something LIKE what you're talking about... check out Multiplex: http://multiplexapp.com/ >From what I understand, every download is shipped with a unique key that can be upgraded for access to the full version of the app... In that way, the download itself has a new consumer key embedded in it. I don't know how this scales across multiple machines or reinstallations, but at least someone is doing it... it's from the folks at Indy Labs: http://labs.indyhall.org/ Chris On Sun, Apr 12, 2009 at 10:57 PM, John Kristian wrote: > > I don't see how OAuth was designed for this. OAuth assumes that the > consumer can keep a secret. > > If the consumer can't keep a secret, then the service provider can't > really authenticate the consumer, and should inform the user of this > fact. The user must decide whether to trust the consumer without help > from the service provider. > > Why not just assume that the consumer secret won't be secret? All > copies of the consumer would use the same consumer key and secret > (baked into the software). Seems like this would fit better into a > service provider's system for identifying consumers and users. > Security would revolve around the access token and token secret. Each > user/consumer pair would have its own access token and token secret. > The service provider would enable a user to revoke her access tokens, > e.g. in case they're stolen. > > Users sharing a computer complicates things. Can other users of the > computer access my credentials (and abuse them)? As a rule, I > wouldn't like other users to be able to revoke my access: they might > abuse the privilege. > > > -- 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: Java Library and java-twitter
To build from the current source, you'll need the java-twitter library. Maven will take care of this, since the dependency is declared in http://oauth.googlecode.com/svn/code/java/core/pom.xml The Twitter-related code will probably move into java-twitter. I've been discussing that with its author. http://groups.google.com/group/java-twitter?hl=en On Apr 13, 11:57 am, Zhihong wrote: > I just checked out the new Java Library today from > http://oauth.googlecode.com/svn/code/java/core/src/main/java but my > program doesn't build anymore because of a new directory called > java_twitter. > > Does java_twitter really belong to core? --~--~-~--~~~---~--~~ 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 -~--~~~~--~~--~--~---
