Hi Scott, Due to my current contractual obligations I can participate in Open Source discussions but not become a main code contributor to any core codebases, since my employer has their own open/commercial products, which is why I've kind of stayed on the fringe just chiming up occasionally.
Luckily within a few weeks I will be a "free agent" again so I can get involved further, but in the meantime I'll try to whip up a standalone version using one of those Java OAuth libs, which could then become an OAuth branch if it worked as planned. Would really appreciate your help/guidance on that when ready. Shouldn't be too hard, especially since there's a pure-Java Twitter example already on Signpost. As they mention there though, so many variations in OAuth implementations (i.e. apps implemented against different drafts/versions/extensions) making it difficult to support all OAuth endpoints. Such a shame, since OAuth was meant to unify implementations not fragment them further, hopefully the newest spec finally gets it right and people can at least agree on the most important aspect of OAuth (IMHO: the authorization flow). In any case, wouldn't want to hold up any builds by saying it will definitely go in 0.8., which I might have missed, but what is the expected release date for it? Bryan BTW... testing the widget for the first time since Twitter API's BASIC auth shutdown, it is definitely broken as expected, so you can search for general public tweets but no longer access private tweets or full user timelines. Will add a patch to this issue as soon as I can put something together. -----Original Message----- From: Scott Wilson [mailto:scott.bradley.wil...@gmail.com] Sent: October 8, 2010 10:38 AM To: wookie-dev@incubator.apache.org Subject: Re: [jira] Updated: (WOOKIE-142) Twitter API Widget On 7 Oct 2010, at 15:43, Copeland, Bryan wrote: > This is true, > > But there are ways to hide the keys, such as in a signed config or XML file > somewhere, even on the server behind the Wookie login, encrypted... but > again, if you expose both your public key and private/secret keys in the > client's JS code, this is little more than obfuscation and could be > discovered by a determined hacker. > > In that case server-side does seem the way to go, how about a similar > approach to the way the JPA integration was handled (kudos to Randy, Scott > and everyone who contributed on that again)... start with a working and > in-use Java OAuth library with OAuth2.0 support and have an Amber branch to > be merged when ready (just as Hibernate was subbed for JPA). That sounds like a good plan. If we can come up with clear APIs at the widget JS end then it shouldn't matter too much if we end up migrating the server code at some point to use a different library. There is also a Token bean in the Wookie source ready to persist token information once we have the rest of the pieces. I think overall we're looking at full 3-legged oAuth rather than the simpler subsets implemented by Shindig. > Two that standout are: > - leeloo: http://bitbucket.org/smartproject/oauth-2.0/wiki/Home > - Signpost: http://code.google.com/p/oauth-signpost/ (WRAP, not full OAuth2 > yet) I had a look at Signpost - that looks pretty good. Leeloo is new but seems further along than Amber (maybe they should team up?) If you fancy doing some work with either of these I'd be happy to pitch in and help. > Sorry for my ignorance of Amber, if there's some demos that already work or > some code which could be built upon it makes more sense to save the trouble > and start with that first though, but it seems from first look they are still > in very early stages so it could be a while... Yes, I've been keeping tabs on the dev list and it does seem quite early days. > > Bryan > > > -----Original Message----- > From: Scott Wilson [mailto:scott.bradley.wil...@gmail.com] > Sent: October 7, 2010 11:28 AM > To: wookie-dev@incubator.apache.org > Subject: Re: [jira] Updated: (WOOKIE-142) Twitter API Widget > > On 7 Oct 2010, at 15:17, Copeland, Bryan wrote: > >> Agreed... would like to finish it as well, especially since Twitter has >> dropped BASIC authentication, the old way of getting private tweets and >> posting status updates is now obsolete. >> >> Was there a final decision on signing OAuth requests from within a Wookie >> widget? Should we try to do this at the widget-level itself with the OAuth >> Javascript library or pass it to a server-side proxy for handling/storing >> the token negotiation? > >> Also, the version of OAuth to support could weigh on this decision somewhat, >> with 1.0 I'd just try to sign it in JS, but I'm assuming the goal is to >> support version 2.0 of the latest spec as it near completion. Since that >> requires HTTPS all the way through the JS library itself might be obsolete >> and it might need to be signed on the server anyway. >> >> If anyone has any thoughts on which way to go, I can try to wrap this up, > > I was reluctant to commit to us trying to develop an oAuth solution for > Wookie given that there is another Apache podling doing oAuth: > > http://incubator.apache.org/projects/amber.html > > So my inclination would be to try to support Amber and then use it in Wookie > as soon as they have a release, rather than try to do something just for > Wookie. However that does create a dependency between the podlings, and if > ultimately Amber stalls or goes in a direction that doesn't help us then > we're back to square one. > > I had a chat with some Android developers and others and it seems like to use > OAuth 2.0 you really do need to build in local token management (in our case, > local meaning on the Wookie server) and not delegate everything to client JS. > One of the reasons being that you can't distribute an open-source widget with > its consumer key and secret! > >> >> Bryan >> >> -----Original Message----- >> From: Scott Wilson (JIRA) [mailto:j...@apache.org] >> Sent: October 7, 2010 10:44 AM >> To: wookie-dev@incubator.apache.org >> Subject: [jira] Updated: (WOOKIE-142) Twitter API Widget >> >> >> [ >> https://issues.apache.org/jira/browse/WOOKIE-142?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel >> ] >> >> Scott Wilson updated WOOKIE-142: >> -------------------------------- >> >> Fix Version/s: 0.8.2 >> >> Lets finish this up and put it in 0.8.2 >> >>> Twitter API Widget >>> ------------------ >>> >>> Key: WOOKIE-142 >>> URL: https://issues.apache.org/jira/browse/WOOKIE-142 >>> Project: Wookie >>> Issue Type: Improvement >>> Reporter: Bryan Copeland >>> Priority: Trivial >>> Fix For: 0.8.2 >>> >>> Attachments: twitter.wgt >>> >>> >>> This is just a first stab to extending the same methods as Flickr and >>> YouTube widgets into Twitter... >>> It works for read only right now (search by Tweet text or User tweets) >>> For Tweeting/status updates, there is a slight problem with the >>> authentication in the OAuth signing directly from Javascript via the OAuth >>> JS library, so, this may be one case of a widget which does require a >>> server-side OAuth proxy to relay access tokens securely (although, I have >>> seen Yahoo! YQL used to authenticate remotely to Twitter, so it may still >>> be possible) >> >> -- >> This message is automatically generated by JIRA. >> - >> You can reply to this email to add a comment to the issue online. >> >
