Home

Tapestry-security, the comprehensive security package for Tapestry just got a bit more comprehensive with the new 0.4.1 release! 0.4.x is tested with and meant both for T5.2 and T5.3.

We picked up the brand new Apache Shiro 1.2.0 release of which development snapshots we've been running against for months now. We also decided it's time to start eating our own dog food, so we delegated tapestry-security's exception handling to another module from tynamo.org, tapestry-exceptionpage, in order to gracefully handle security responses as redirects, ajax or not. Read more about what tapestry-security can do for you from tapestry-security guide. Special thanks to Lenny Primak for relentlessly bugging us until we just had to get the 0.4.1 out the door

Release notes:

Bug

• [TYNAMO-102] - Specify id for RequestExceptionHandler advice for preventing unintentional override
• [TYNAMO-103] - @Security, tapestry.secure-enabled, MetaDataConstants.SECURE_PAGE not honored by Tapestry security
• [TYNAMO-105] - Warning is issued in the log file on every startup

Improvement

• [TYNAMO-87] - Redirects should honor localization
• [TYNAMO-106] - Login screen background file (login-bg.png) is too large for the web - smaller file attached
• [TYNAMO-109] - Allow Unauthorized and Login page to be a single page
• [TYNAMO-110] - redirect to login page for pages secured with @RequiresXXX annotations
• [TYNAMO-113] - Test for ajax in the AccessControlFilter.issueRedirect and issue a client-side "soft" redirect if so
• [TYNAMO-117] - Add symbol for disabling redirect to saved request
• [TYNAMO-118] - Store savedrequest into a cookie instead of session
• [TYNAMO-119] - In SecurityFilterChainFactoryImpl, use componentClassResolver to resolve pageclasses to urls

New Feature

• [TYNAMO-111] - Add support for SslFilter & PortFilter

Winter is still in full swing, but the hibernation period for Tynamo is clearly over. I don't want to steal any of Alex' thunder from his JDO release, but on the heels of it we quickly shipped another release from our module warehouse. Tapestry-exceptionpage 0.1.1 is particularly useful, so handy in fact that we even started using it ourselves  Tapestry-exceptionpage forms the foundation for handling exceptions in our upcoming tapestry-security 0.4.1 release. Read more from tapestry-exceptionpage guide.

Release notes:

Bug

• [TYNAMO-97] - tynamo-exceptionpage doesn't handle operationexceptions

Improvement

• [TYNAMO-112] - Properly handle ajax "redirects"
• [TYNAMO-114] - Improve exception cause handling and documentation

I am excited to announce the release of the new addition to Tynamo's beautiful set of modules : tapestry-jdo . It brings the idioms that many Tapestry developers have come to enjoy w/ Hibernate and JPA to JDO users. Read more on the Tapestry JDO Guide.

This module has been a long time in the making - the initial commit of the basic functionality was added about 6 months ago when I had just finished working on a JDO based app running on Google App Engine. The module was inspired by the tapestry-jpa module at Tynamo. 

JDO as a standard is a curious beast. It was the first attempt at building solid ORM functionality for the Java platform, there were a bunch of solid implementations out there (Apache JDO, Kodo, etc); however, it somehow never managed to catch fire like Hibernate. For a while, at least for me, it felt like the standard was on its way out, giving way to JPA; yet, it keeps coming back: Google App Engine JDO support, MongoDB JDO API through DataNucleus, etc.  

Enjoy !

After grueling six months of development on Android, I'm back at the server side. I'll be cutting a new, T5.3 specific version of Tynamo's tapestry-security in the near future, though unfortunately it won't make it to Santa's sleigh. I'm hoping to also pick up Shiro 1.2 as a dependency if we get that finalized in time. If there's anything you really wanted to change or fix in tapestry-security but never got around reporting it, right about now would be a good time. All the currently open issues will be resolved as well. Thanks to all, it's been a great year for Tynamo as well as Tapestry!

Please join me in welcoming Alex Kotchnev, our newest Tynamo committer! What has almost become a tradition, a new committer brings a few gifts and so does Alex, namely a new Tapestry integration module for JDO2. We imported the new, aptly named tapestry-jdo module into our repository in no time and patted Alex on the back as a signal to start hacking! More to follow I'm sure. Hey Alex, where's that jdo release again I needed yesterday? Just kidding, no pressure

You've spoken and we aim to please! In tapestry-security 0.4.0 we did away with the shiro.ini and allowed configuring security Tapestry-style with all-in-Java contributions. The release finally combines all features from separate Shiro integrations (original tapestry-security by Kalle Korhonen) and tapestry-jsecurity (originally by Valentin Yerastov). We'll be adding a few signatures in minor revisions, but the interfaces are already stable and the release is fully integration tested against T5.2.5. Among other improvements are some performance enhancements: processing Shiro filter chains should be much quicker with 0.4.0. More information at tapestry-security guide.

Release notes:
Improvement
TYNAMO-67 - Allow contributing new security filters
New Feature
TYNAMO-76 - Re-write the built-in Shiro filters as Tapestry filters

Enjoy!
Tynamo Team

Here comes yet another beautiful little module called tapestry-routing.

In a nutshell, tapestry-routing allows you to provide your own custom mapping between Tapestry pages and URLs.

Did you ever wanted to change the order of the path params in an URL? now you can!

Let's say you have a page: pages.projects.Members which have 2 parameters in its activation context: (Long projectId, Long memberId) and you want the URL for that page to look like /projects/1/members/1 Just add the @At annotation to you page, like this:

That's it!
tapestry-routing Dispatcher will take care of recognizing incoming requests and dispatching the proper render request
tapestry-routing PageRenderLinkTransformer will do the rest of the work, it will transform every Link for a page render request formatting it according to your route rule.

We really need some feedback, so please give it a try:http://tynamo.org/tapestry-routing+guide

Enjoy!

Whoops, almost forgot to announce the release of our latest module here: 0.0.1 version of tynamo-federatedaccounts with Facebook Oauth is now out! Additional openID & Oauth providers to follow. More at tynamo-federatedaccounts guide. Also see the previous blog entry for more information.

Release notes:

Improvement

TYNAMO-74 - Support inline Facebook oauth permission screen

New Feature

TYNAMO-72 - Initial implementation of Facebook Oauth
TYNAMO-73 - Initial implementation of federatedaccounts sample
running on GAE
TYNAMO-80 - Implement different windowmodes for Facebook oauth

Here's what Alejandro (the co-founder of Tynamo) had to say about the module:
I don't know if we should release this module, It's so easy to use that's not fair for people that suffered the Facebook nightmare. I want people to suffer as I DID!!! Damn it Kalle!! Excellent work!

Also check out the live example of federatedaccounts. Enjoy!

Last week, I was working on improving the initial implementation for federatedaccounts. Some of you might have preferred that I spend my time implementing more OAuth providers or a generic OpenId provider but since I have the itch to scratch, I instead decided on implementing a configurable window mode for the existing Facebook Oauth integration, in order to improve its usability and customizability. Now, the window mode refers to how the (the response to the) callback URL is presented to the user. Three basic choices is either self, blank or inline. See our federatedaccounts demo if you don't know what these mean. Self and blank should be straight-forwarded, but by attempting to implement inline (just to see how far I'd get with it...), i.e. an (i)frame-based window mode, I of course landed right in the middle of the whole clickjacking or UI redressing attack controversy. The core problem is that browsers and the html standards don't provide any good, end-user friendly means for verifying the origins of an iframe content. Therefore, the security conscious Oauth folks (see e.g. http://simonwillison.net/2009/Jul/16/responsibility/) say (rightly so) that you should never ever allow processing an Oauth request in an iframe since the URL is not shown to the user and it's simple to fake the dialog UI. In contrast, the user experience experts argue that popping out windows or suddenly transferring the user to a different site makes the user feel more confused and insecure (see e.g. http://drstarcat.com/archives/133), and that the frame busters are meaningless as the majority of users won't pay any attention to the URL anyway. I happen to agree with both sides. Relying on the user to validate the URL, especially without any additional visual clues (compare to how modern browsers display https URLs with valid SSL certifates) is way too weak as a real security measure, but if that's all you got, it's certainly better than nothing. On the usability side, launching a new browser window, or doing a full page refresh, is somewhat confusing and way slower than loading content into a pre-existing iframe. What's lost in all of this, is that Oauthis supposed to be about authorizing users, not authenticating them.

Notice how above I first blamed the browsers for not solving the problem, but then ended up sharing the blame with OAuth. That's because a) the UI redressing problem is not specific to OAuth and b) UI redressing is a super-tricky problem to solve. Simply displaying the URL of an iframe (even if browser assisted) is not nearly enough because that too can be easily redressed (see more at http://www.webmonkey.com/2008/10/a_look_at_the__clickjacking__web_attack_and_why_you_should_worry/). Browser developers do are trying to do something about the problem but they just don't agree on exactly what is the right measure (see e.g http://lists.whatwg.org/pipermail/whatwg-whatwg.org/2008-September/016286.html).

So, while waiting for a standards-based solution to the problem is there anything that can be done to improve the user experience of (FB's) OAuth dialog flow? The inline window mode works great if a) you are already authenticated with Facebook (i.e. you have a valid Facebook cookie) and b) you've previously authorized the subject application. However, in all other cases, the inline mode isn't too useful since it's not that simple to find out if the current user is logged onto Facebook or not. You can find the status with FB.getLoginStatus() but you have to include FB's Javascript SDK to the page. The other issue is the frame busting code. Facebook doesn't allow any of its pages to be displayed in an iframe. Instead they simply display a link to "Visit Facebook" when shown in an IFrame. There's no technical or security-related reason why Facebook couldn't allow showing the Oauth authorization window in an iframe when the user is pre-authenticated via cookies. In fact, Facebook already (almost) had this working with Facebook Connect, only it had one crucial flaw: it was asking for user's Facebook username and password in the same dialog.

To improve usability without asking for user's credentials in the same Oauth authorization dialog, Facebook could potentially allow passing a one-time valid user authentication token with the Oauth request, but in some ways that would only shift the responsibility somewhere else. There's an open standard for that as well, called OpenID, and you can by all means use OpenID together with OAuth as demonstrated by Google . Unfortunately though, the window redressing attack is just as big of a problem for OpenID as it is for OAuth. Since OpenID was originally meant for authentication only (though the attribute extensions make it partly an authorization technique) you cannot shift the responsibility any further. I'm not advocating the use of hybrid OpenID+Oauth model either - it may just increase complexity without improving user experience. However, we may be throwing the baby out with the bath water by never allowing Oauth dialogs to be shown in iframes. Certainly the authorization server has to be able to authenticate the end user one way or another, but handling an Oauth callback in an iframe is perfectly secure if you never ask the user's password in the same dialog. Anyhow, with the current standards there's no way out without major security implications, so browsers and ultimately, newer standards need to provide a better, more secure solution.

This is a patch release to fix: Bug TYNAMO-75 - Security module does not protect urls correctly Separately, I've also added several improvements to the tapestry-security documentation and added links to examples to showcase the capabilities of the module.

With 600 million users and counting, it's the new Internet. Yes, I'm talking about Facebook. Whether you love it or hate it, these days you have to have a Facebook strategy. Every other site is doing Facebook, Twitter and Google integrations and why not, your fledgling little website wouldn't need more than 1/1000th of their users to make it a success. So why is that everybody needs to suffer on their own through implementing various versions of Oauth & other open authorization standards?…

I'm happy to announce that Pierce T. Wetter has joined the ranks of Tynamo. Of course, as one of the original contributors to tapestry-jpa, he's not really a new committer, but hey we'll take it, so welcome on board Pierce! In regards to JPA, I believe we have some quite exciting stuff to introduce in the coming months.

Lately, I've had noticeably more people asking me about Tapestry and why one should choose it over the other (Java) web frameworks. To me, Tapestry is a good compromise, just like Java is. Linus Torvalds, my fellow country man, has famously said "performance almost always matters". There are so many aspects to web development, and performance is often seen as one of the smallest of your problems because in the end "it always comes down to the database". However,…

What's that? Did the little Tynamo elf just leave an early Christmas gift for all the Tapestry people who have been so good boys and girls the whole year? Indeed, Tynamo is announcing one more module, tynamo-archetype 0.1.0 this year before focusing on our own wish list. It seems fitting that we released our very first Tynamo archetype just a year ago and now, 0.1.0 is all ready to go with tynamo-model 0.1.0, T5.2.x and other bells and whistles. Read more from Quick start. Enjoy!…

Hey, wouldn't it be great if you could just reload your RESTful service classes live while developing them? Oh that's right, that's exactly what tapestry-resteasy 0.2.1 allows you to do! This is T5.2.x specific maintenance release, updating the JAX-RS dependency to JBoss' resteasy GA release 2.0.1. Read more at tapestry-resteasy guide. Release notes: Improvement TYNAMO-64 - Live Class Reloading for REST services