Into the symmetry

Some time ago I was looking for a Java OAuth library in order to help me to develop an OAuth aware server application. The natural place where to look for those information was the OAuth website that lists about 4 different Java libraries. The only one I am familiar with is Scribe . Indeed it is a really light, well documented and universally used library to build OAuth clients. It also contains out of the box integration for many well known websites that use OAuth (e.g. Facebook, Twitter, and many more). Unlikely though Scribe did/does not have any support for OAuth server side (that was my original problem). After a while a colleague of mine point me out an Apache project called Apache Amber and it turned out it was what I needed :) (Still wonder why Apache Amber is not listed in the OAuth website though). So the lesson learned is that if you are looking for a simple way to build your OAuth server do not hesitate to use Apache Amber. Here you can see how easy is to build the...

According to http://developers.facebook.com/docs/authentication/ in order to programmatically log the user out of Facebook from an OAuth 2 client (single sign-off) is enough to redirect the user to https://www.facebook.com/logout.php?     next=YOUR_REDIRECT_URL    &access_token=USER_ACCESS_TOKEN This would require a valid access token and a valid redirect url. Alternatively this can be achieved client side by calling FB.logout() . In practice though there is a third (obviously not documented) unofficial way to achieve the same. It is the case indeed that the standard log out form of Facebook suffer from CSRF. Indeed while posting to http://www. facebook .com/ logout .php the related form uses a field,  fb_dtsg , that is supposed to be an anti-CSRF token, however it is not verified properly/at all. Removing this field still resulted in successful logout ! According to Facebook (I have been in touch with them about this) this is not a sec...

It means nothing to a lot of people. It does means a lot to me! My first commit to an Apache project: http://svn.apache.org/viewvc?view=revision&revision=1236276

Time for a little self celebration :) After a flaw found about couple of years ago, a half goof last year and some information disclosure found lately I am now officially Facebook white hat . Cool... A.

It is time to return back to work, after a well deserved break. Following the release 1.0 is time to think about the next release. Well, version 1.0 is available and up-and-running but I bet a lot of people wouldn't find it really useful. This because for to use it, you need to disable the WAS security. It can be acceptable if both Hudson and WAS seat in the same (well protected) LAN and, for example the, WAS is a machine used from the developers as Reference box. But if WAS needs to be well secured and/or in production alas. Now next release should cover WAS 6.1/7 with security enabled. I have already a working proof of concept so it is just matter of polish a bit the code. Here start the "bad news". For having the deploy websphere builder to work with security enabled you need an IBM JRE. This sounds as a big limitation and infact it is. To overcome it you need to install the hudson.war in WAS rather than in Tomcat for example. Well to be perfectly honest though whoe...

As promise: http://wiki.hudson-ci.org/display/HUDSON/Deploy+WebSphere+Plugin More to follow!! A.

Ready to ship! Eventually I have decided to go for a new plugin having a dependency with the existing deploy plugin. This, in my opinion, is the best solution because, being WebSphere a proprietary product and being some jar not redistributable there is a needing of a little extra configuration (just copying a couple of proprietary jar on the classpath) at the end of the plugin installation. Anyway more details will be on the wikis (either my personal one and the one of hudson if I can publish my plugin) once I got the right to check-in on the hudson java.net repository. So hung on for a little while.... Antonio