Sure man....here is what I am doing, but please read the notes afterwards, cause I am still learning and I think parts of this process are either not secure and/or won't work in practice. But it did work at 4am last night (and I had only had like 4 beers.... :) )
I used twitter4j, and followed this blog post: http://jeungun.wordpress.com/2009/09/03/quick-and-dirty-twitter4j-oauth-for-web-apps/ The main difference being that I didn't use 2 servlets. I have one 'twitterservice' servlet that sits on the server, and I do GWT-RPC to talk to that & let it do all the heavy lifting. (also acts as a proxy for the same origin issues). The basic workflow is: - check if I have a access token cookie already - if I have the token cookie, give it to twitter4j, and make calls right away. - if no cookie yet, check for a RequestToken on the server, if none, show 'login with twitter' button - on click of the button, call 'getoauthURL' gwt-rpc on servlet - in getOAuthURL I persist the RequestToken on the server temporarily, and return the oauth URL - back in the clientside, I do a window load to the URL, and let the user authorize the app - once authorized, twitter redirects back to my apps listed URL (see note below) - now back in the client side we still don't have an access cookie, but we DO have a request token - so, this time, call 'getAccessToken' gwt-rpc on the servlet. - save the access token & secret in cookies for the future. Notes: - I persist the request token on the servlet. This is probably due to my lack of web programming background (20+ years of desktop programming, just started with the web now!). Can I do that? Is it safe to just save something in a variable on the server side, or is the servlet instance shared with everyone, thus this process only works in development when I am the only one connecting? This isn't really an issue I suppose, cause I could always store the request token on the client side in a cookie, the same way I do the access token later. - That leads to my second note/question... is it 'safe and secure' to store the access token & secret in a cookie? Is that the expected way of doing it in this case? I do pass the token and secret during the gwt-rpc calls, so I don't know if that defeats the purpose when you expose the secret like that. - Lastly, one gotcha (at least for development) is that twitter won't redirect to localhost, so I just put in my blog url. It redirects there after authorization, but it doesn't matter cause we persist the request token prior to leaving the page, so just go back to localhost by hand, and everything should be happy. -pj On Sun, Sep 13, 2009 at 12:18 PM, Jeff Chimene <[email protected]> wrote: > > On 09/13/2009 08:39 AM, PJ Gray wrote: > > Thanks for the help. I messed around with it a bit more, and just kept > > getting frustrated. Uggg, just isn't this hard if I want a > > non-integrated solution in XCode....why is it here? Anyway, I settled > > on just zipping up my whole folder and putting the zip in source > > control. Big hammer solution, I know...but whatever, I was wasting too > > much time figuring out stuff that should 'just work'. > > > > When I get some free cycles I'll take my questions to an Eclipse related > > forum and maybe make some progress. > > > > thanks again! (just got twitter oauth working in my GWT app last > > night! woohoo!!!) > > By way of thanks, would you please post some code? > > > > > -pj > > > > > > > > On Sat, Sep 12, 2009 at 3:33 PM, Jeff Chimene <[email protected] > > <mailto:[email protected]>> wrote: > > > > > > On 09/12/2009 10:41 AM, PJ Gray wrote: > > > So maybe I am not fully understanding the versioning situation. > > > > > > I did some research last night, and attempted to get my project > under > > > source control, without any luck. It appears to me that I am > > required > > > to use Subclipse as my subversion client because of some special > way > > > that Eclipse handles projects? > > > > I don't think so. I think Subclipse is popular because it's a good > > Subversion client. However, there may be other Eclipse Subversion > > clients. > > > > > If that is the case, then I suppose > > > I'll take my question to an Eclipse-specific forum. > > > However, it seems like I should be able to use whatever client I > want! > > > > Probably not in the way that I think you mean that statement. Eclipse > > SVN clients are designed to integrate into the Eclipse environment. > It's > > not really a matter of bolting-on any SVN client. IDE users expect > the > > functional bar to be set higher than that. I have to admit that I > don't > > know Versions, but even if it is a GUI, and there is no Eclipse > plugin, > > it's only going to work as an external to Eclipse. If you reeeeely > want > > to stick with Versions, you'll have to figure out why Eclipse lost > its > > mind when the source went into SVN. > > > > > However, when I would add things mentioned in these emails to > source > > > control on my desktop, then checkout on my laptop, the GWT project > was > > > no longer listed in the Eclipse workspace. Even when I added > > everything > > > in the hidden folders to source control, it still wasn't listed in > the > > > workspace. I couldn't find the "special sauce" that told Eclipse > that > > > my project was part of the workspace, and how it was configured. > > > > Just to be clear: you ADDed the source of an existing Eclipse project > to > > Subversion via Versions? I'm guessing that somehow that shifted the > > project contents underneath Eclipse, and it got confused. But, I > can't > > really tell from this description. It sounds like the next step is to > > get a working Eclipse project back. I'd checkout the SVN source and > then > > import it as an existing project (since you added the Eclipse > .project > > and .settings/ to SVN) > > > > You're right, this is not a GWT-related topic. > > > > You have to tell Eclipse where to find your SVN repository. > > > > To do that, you'll have to install an Eclipse SVN plugin. If you > don't > > want to do that, you'll have to manage your repository outside > Eclipse, > > and figure out why Eclipse lost the project after adding that project > to > > the repository. > > > > If you decide to use Subclipse, be sure to understand that to get the > > best performance, you must install the JavaHL library. The Subclipse > > client will work w/o JavaHL, but it will lack some features. The > > Subclipse wiki goes into detail about that issue. > > > > > > > > > > > > --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "Google Web Toolkit" 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/google-web-toolkit?hl=en -~----------~----~----~----~------~----~------~--~---
