You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@wookie.apache.org by "Scott Wilson (JIRA)" <ji...@apache.org> on 2010/10/07 15:43:31 UTC
[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.
Re: Branching strategy (was Re: [jira] Updated: (WOOKIE-142) Twitter
API Widget)
Posted by Ross Gardler <rg...@apache.org>.
On 12/10/2010 01:43, Kris Popat wrote:
>
> On 11 Oct 2010, at 21:22, Scott Wilson wrote:
>
>>
>> On 11 Oct 2010, at 18:06, Luciano Resende wrote:
>>
>>> On Mon, Oct 11, 2010 at 10:01 AM, Ross Gardler <rg...@apache.org>
>>> wrote:
>>>> On 11/10/2010 04:06, Scott Wilson wrote:
>>>>>
>>>>> (Maybe we need another discussion around branching strategy - e.g. do
>>>>> we have different branches for release versions (e.g. a 0.9.0 branch
>>>>> and a 0.9.1. branch), or do we keep on having the current code in
>>>>> trunk and just do potentially-disruptive feature development in
>>>>> branches?)
>>>>
>>>> There are many ways of doing this. The way I personally prefer (but
>>>> never
>>>> insist upon, others should suggest alternatives) is:
>>>>
>>>> - at code freeze for a release create a branch in which the release
>>>> will be
>>>> built (this allows development to continue in trunk even while
>>>> release build
>>>> and testing is underway)
>>>>
>>>> - once the release is approved and built tag trunk as 0.9.0 or whatever
>>>>
>>>> - use the branch for maintenance of the release (i.e. security fixes
>>>> that
>>>> can't wait for the next release from trunk)
>>>>
>>>
>>> +1, this makes it easy to have maintenance release (e.g 0.9.1, 0.9.2,
>>> etc). I'd just mention that, for the maintenance release it's probably
>>> enough to just have a tag created and continue to use the same branch
>>> (e.g 0.9.0)
>>
>> +1 also. I was thinking about how we might start work on the oAuth
>> integration and other new features while still being able to make
>> maintenance releases of 0.9.0 if there are critical bugs found. I
>> think that answers it nicely.
>>
>
> +1 yes, I was thinking this myself, the only issue that we might need to
> be aware of is if testing of the release package comes up with some
> issues that need to be fixed then we also need to remember to merge
> those fixes back into truck.
Yes, that's the "downside" of branching rather than doing a code freeze.
In a small community like this a code freeze for a short period is
usually not a major problem. However, as the community grows the
overhead of managing the branch and trunk is worthwhile and has to be
done anyway for emergency maintenance releases of the branch.
Ross
Re: Branching strategy (was Re: [jira] Updated: (WOOKIE-142) Twitter
API Widget)
Posted by Ross Gardler <rg...@apache.org>.
On 21/10/2010 09:20, Thomas Ernest wrote:
> Hi,
>
> On 10/12/2010 10:43 AM, Kris Popat wrote:
>>
...
>>>> On Mon, Oct 11, 2010 at 10:01 AM, Ross Gardler<rg...@apache.org>
>>>> wrote:
...
>>>>> - once the release is approved and built tag trunk as 0.9.0 or
>>>>> whatever
> My question will probably sounds stupid, but I would like to understand.
> Why do we make a tag from trunk and not from the branch ?
> Besides, where will be committed changes between branch creation and tag
> build : trunk, branch, branch then trunk or trunk then branch ? I mean
> there are several cases : bug fix in trunk, bug fix in branch and
> probably some other ones ?
That's not a stupid question, it's a very sensible one. It highlights an
error in the proposed process, we should indeed be tagging from the branch.
So:
branch for the release
test and fix bugs in the branch (merging them with trunk)
continue development in trunk (but don't merge anything other than bug
fixes to branch - and only using a review then commit process)
tag from branch (not trunk as we originally agreed)
Ross
Re: Branching strategy (was Re: [jira] Updated: (WOOKIE-142) Twitter
API Widget)
Posted by Thomas Ernest <th...@gmail.com>.
Hi,
On 10/12/2010 10:43 AM, Kris Popat wrote:
>
> On 11 Oct 2010, at 21:22, Scott Wilson wrote:
>
>>
>> On 11 Oct 2010, at 18:06, Luciano Resende wrote:
>>
>>> On Mon, Oct 11, 2010 at 10:01 AM, Ross Gardler <rg...@apache.org>
>>> wrote:
>>>> On 11/10/2010 04:06, Scott Wilson wrote:
>>>>>
>>>>> (Maybe we need another discussion around branching strategy - e.g. do
>>>>> we have different branches for release versions (e.g. a 0.9.0 branch
>>>>> and a 0.9.1. branch), or do we keep on having the current code in
>>>>> trunk and just do potentially-disruptive feature development in
>>>>> branches?)
>>>>
>>>> There are many ways of doing this. The way I personally prefer (but
>>>> never
>>>> insist upon, others should suggest alternatives) is:
>>>>
>>>> - at code freeze for a release create a branch in which the release
>>>> will be
>>>> built (this allows development to continue in trunk even while
>>>> release build
>>>> and testing is underway)
>>>>
>>>> - once the release is approved and built tag trunk as 0.9.0 or
>>>> whatever
My question will probably sounds stupid, but I would like to understand.
Why do we make a tag from trunk and not from the branch ?
Besides, where will be committed changes between branch creation and tag
build : trunk, branch, branch then trunk or trunk then branch ? I mean
there are several cases : bug fix in trunk, bug fix in branch and
probably some other ones ?
>>>>
>>>> - use the branch for maintenance of the release (i.e. security
>>>> fixes that
>>>> can't wait for the next release from trunk)
>>>>
>>>
>>> +1, this makes it easy to have maintenance release (e.g 0.9.1, 0.9.2,
>>> etc). I'd just mention that, for the maintenance release it's probably
>>> enough to just have a tag created and continue to use the same branch
>>> (e.g 0.9.0)
>>
>> +1 also. I was thinking about how we might start work on the oAuth
>> integration and other new features while still being able to make
>> maintenance releases of 0.9.0 if there are critical bugs found. I
>> think that answers it nicely.
>>
>
> +1 yes, I was thinking this myself, the only issue that we might need
> to be aware of is if testing of the release package comes up with some
> issues that need to be fixed then we also need to remember to merge
> those fixes back into truck.
>
>
>>>> Creating branches for disruptive features is important to allow
>>>> people to
>>>> continue to develop in trunk. However, they should only be created
>>>> when
>>>> really necessary as it can be difficult to maintain a branch.
>>>>
>>>
>>> +1, and they should be merged back as soon as they are stable and
>>> people agree with it.
>>
>> +1 It was good to work with Randy on the JPA/JCR stuff in a branch
>> for this purpose, but it was a lot of overhead to keep it in sync
>> with trunk, so I'd definitely prefer to only do this for major
>> replumbing.
>>
>
> +1
+1 I got this one, no need for explanation ;-)
>>>> Whatever policy is adopted needs to be documented in the relase
>>>> management
>>>> documents I hope Kris will put together as he works through this
>>>> process.
>>>>
>>>
>>> +1
>> +1
>
> +1 Yes am working on some initial release management documents at the
> moment on the wiki, will post later when they are up
+1 Thank you for documenting all of that.
Thomas.
Re: Branching strategy (was Re: [jira] Updated: (WOOKIE-142) Twitter API Widget)
Posted by Kris Popat <kj...@gmail.com>.
On 11 Oct 2010, at 21:22, Scott Wilson wrote:
>
> On 11 Oct 2010, at 18:06, Luciano Resende wrote:
>
>> On Mon, Oct 11, 2010 at 10:01 AM, Ross Gardler
>> <rg...@apache.org> wrote:
>>> On 11/10/2010 04:06, Scott Wilson wrote:
>>>>
>>>> (Maybe we need another discussion around branching strategy -
>>>> e.g. do
>>>> we have different branches for release versions (e.g. a 0.9.0
>>>> branch
>>>> and a 0.9.1. branch), or do we keep on having the current code in
>>>> trunk and just do potentially-disruptive feature development in
>>>> branches?)
>>>
>>> There are many ways of doing this. The way I personally prefer
>>> (but never
>>> insist upon, others should suggest alternatives) is:
>>>
>>> - at code freeze for a release create a branch in which the
>>> release will be
>>> built (this allows development to continue in trunk even while
>>> release build
>>> and testing is underway)
>>>
>>> - once the release is approved and built tag trunk as 0.9.0 or
>>> whatever
>>>
>>> - use the branch for maintenance of the release (i.e. security
>>> fixes that
>>> can't wait for the next release from trunk)
>>>
>>
>> +1, this makes it easy to have maintenance release (e.g 0.9.1, 0.9.2,
>> etc). I'd just mention that, for the maintenance release it's
>> probably
>> enough to just have a tag created and continue to use the same branch
>> (e.g 0.9.0)
>
> +1 also. I was thinking about how we might start work on the oAuth
> integration and other new features while still being able to make
> maintenance releases of 0.9.0 if there are critical bugs found. I
> think that answers it nicely.
>
+1 yes, I was thinking this myself, the only issue that we might need
to be aware of is if testing of the release package comes up with some
issues that need to be fixed then we also need to remember to merge
those fixes back into truck.
>>> Creating branches for disruptive features is important to allow
>>> people to
>>> continue to develop in trunk. However, they should only be created
>>> when
>>> really necessary as it can be difficult to maintain a branch.
>>>
>>
>> +1, and they should be merged back as soon as they are stable and
>> people agree with it.
>
> +1 It was good to work with Randy on the JPA/JCR stuff in a branch
> for this purpose, but it was a lot of overhead to keep it in sync
> with trunk, so I'd definitely prefer to only do this for major
> replumbing.
>
+1
>>> Whatever policy is adopted needs to be documented in the relase
>>> management
>>> documents I hope Kris will put together as he works through this
>>> process.
>>>
>>
>> +1
> +1
+1 Yes am working on some initial release management documents at the
moment on the wiki, will post later when they are up
>>
>>
>> --
>> Luciano Resende
>> http://people.apache.org/~lresende
>> http://twitter.com/lresende1975
>> http://lresende.blogspot.com/
>
Re: Branching strategy (was Re: [jira] Updated: (WOOKIE-142) Twitter API Widget)
Posted by Scott Wilson <sc...@gmail.com>.
On 11 Oct 2010, at 18:06, Luciano Resende wrote:
> On Mon, Oct 11, 2010 at 10:01 AM, Ross Gardler <rg...@apache.org> wrote:
>> On 11/10/2010 04:06, Scott Wilson wrote:
>>>
>>> (Maybe we need another discussion around branching strategy - e.g. do
>>> we have different branches for release versions (e.g. a 0.9.0 branch
>>> and a 0.9.1. branch), or do we keep on having the current code in
>>> trunk and just do potentially-disruptive feature development in
>>> branches?)
>>
>> There are many ways of doing this. The way I personally prefer (but never
>> insist upon, others should suggest alternatives) is:
>>
>> - at code freeze for a release create a branch in which the release will be
>> built (this allows development to continue in trunk even while release build
>> and testing is underway)
>>
>> - once the release is approved and built tag trunk as 0.9.0 or whatever
>>
>> - use the branch for maintenance of the release (i.e. security fixes that
>> can't wait for the next release from trunk)
>>
>
> +1, this makes it easy to have maintenance release (e.g 0.9.1, 0.9.2,
> etc). I'd just mention that, for the maintenance release it's probably
> enough to just have a tag created and continue to use the same branch
> (e.g 0.9.0)
+1 also. I was thinking about how we might start work on the oAuth integration and other new features while still being able to make maintenance releases of 0.9.0 if there are critical bugs found. I think that answers it nicely.
>> Creating branches for disruptive features is important to allow people to
>> continue to develop in trunk. However, they should only be created when
>> really necessary as it can be difficult to maintain a branch.
>>
>
> +1, and they should be merged back as soon as they are stable and
> people agree with it.
+1 It was good to work with Randy on the JPA/JCR stuff in a branch for this purpose, but it was a lot of overhead to keep it in sync with trunk, so I'd definitely prefer to only do this for major replumbing.
>> Whatever policy is adopted needs to be documented in the relase management
>> documents I hope Kris will put together as he works through this process.
>>
>
> +1
+1
>
>
> --
> Luciano Resende
> http://people.apache.org/~lresende
> http://twitter.com/lresende1975
> http://lresende.blogspot.com/
Re: Branching strategy (was Re: [jira] Updated: (WOOKIE-142) Twitter
API Widget)
Posted by Luciano Resende <lu...@gmail.com>.
On Mon, Oct 11, 2010 at 10:01 AM, Ross Gardler <rg...@apache.org> wrote:
> On 11/10/2010 04:06, Scott Wilson wrote:
>>
>> (Maybe we need another discussion around branching strategy - e.g. do
>> we have different branches for release versions (e.g. a 0.9.0 branch
>> and a 0.9.1. branch), or do we keep on having the current code in
>> trunk and just do potentially-disruptive feature development in
>> branches?)
>
> There are many ways of doing this. The way I personally prefer (but never
> insist upon, others should suggest alternatives) is:
>
> - at code freeze for a release create a branch in which the release will be
> built (this allows development to continue in trunk even while release build
> and testing is underway)
>
> - once the release is approved and built tag trunk as 0.9.0 or whatever
>
> - use the branch for maintenance of the release (i.e. security fixes that
> can't wait for the next release from trunk)
>
+1, this makes it easy to have maintenance release (e.g 0.9.1, 0.9.2,
etc). I'd just mention that, for the maintenance release it's probably
enough to just have a tag created and continue to use the same branch
(e.g 0.9.0)
> Creating branches for disruptive features is important to allow people to
> continue to develop in trunk. However, they should only be created when
> really necessary as it can be difficult to maintain a branch.
>
+1, and they should be merged back as soon as they are stable and
people agree with it.
> Whatever policy is adopted needs to be documented in the relase management
> documents I hope Kris will put together as he works through this process.
>
+1
--
Luciano Resende
http://people.apache.org/~lresende
http://twitter.com/lresende1975
http://lresende.blogspot.com/
Branching strategy (was Re: [jira] Updated: (WOOKIE-142) Twitter
API Widget)
Posted by Ross Gardler <rg...@apache.org>.
On 11/10/2010 04:06, Scott Wilson wrote:
> (Maybe we need another discussion around branching strategy - e.g. do
> we have different branches for release versions (e.g. a 0.9.0 branch
> and a 0.9.1. branch), or do we keep on having the current code in
> trunk and just do potentially-disruptive feature development in
> branches?)
There are many ways of doing this. The way I personally prefer (but
never insist upon, others should suggest alternatives) is:
- at code freeze for a release create a branch in which the release will
be built (this allows development to continue in trunk even while
release build and testing is underway)
- once the release is approved and built tag trunk as 0.9.0 or whatever
- use the branch for maintenance of the release (i.e. security fixes
that can't wait for the next release from trunk)
Creating branches for disruptive features is important to allow people
to continue to develop in trunk. However, they should only be created
when really necessary as it can be difficult to maintain a branch.
Whatever policy is adopted needs to be documented in the relase
management documents I hope Kris will put together as he works through
this process.
Ross
Re: [jira] Updated: (WOOKIE-142) Twitter API Widget
Posted by Scott Wilson <sc...@gmail.com>.
On 8 Oct 2010, at 16:16, Copeland, Bryan wrote:
> 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.
That sounds fantastic! Definitely count me in.
(Maybe we need another discussion around branching strategy - e.g. do we have different branches for release versions (e.g. a 0.9.0 branch and a 0.9.1. branch), or do we keep on having the current code in trunk and just do potentially-disruptive feature development in branches?)
> 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).
I know, an implementation now is going to have to handle a bunch of different "flavours" of oAuth.
> 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?
We're hoping to have the release (0.9) done within the next 2 weeks, so I've put the oAuth stuff tentatively against the release after that (which doesn't have a date yet). Which looks like it fits your timescale nicely!
> 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.wilson@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.wilson@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:jira@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.
>>>
>>
>
RE: [jira] Updated: (WOOKIE-142) Twitter API Widget
Posted by "Copeland, Bryan" <Br...@nrc-cnrc.gc.ca>.
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.wilson@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.wilson@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:jira@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.
>>
>
Re: [jira] Updated: (WOOKIE-142) Twitter API Widget
Posted by Scott Wilson <sc...@gmail.com>.
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.wilson@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:jira@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.
>>
>
RE: [jira] Updated: (WOOKIE-142) Twitter API Widget
Posted by "Copeland, Bryan" <Br...@nrc-cnrc.gc.ca>.
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). 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)
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...
Bryan
-----Original Message-----
From: Scott Wilson [mailto:scott.bradley.wilson@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:jira@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.
>
Re: [jira] Updated: (WOOKIE-142) Twitter API Widget
Posted by Scott Wilson <sc...@gmail.com>.
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:jira@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.
>
RE: [jira] Updated: (WOOKIE-142) Twitter API Widget
Posted by "Copeland, Bryan" <Br...@nrc-cnrc.gc.ca>.
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,
Bryan
-----Original Message-----
From: Scott Wilson (JIRA) [mailto:jira@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.