At long last, we've gotten off our collective lazy ass and worked harder than ever for free to bring you tapesty-federatedaccounts 0.1.0, with twitter as the new authentication provider. Some jokesters might question why it took so long since we are just using the super-great twitter4j library, which is almost as good as RestFB that we use for Facebook integration. We are first to admit that twitter4j takes all the pain away from Oauth 1.0a's obnoxious request signing business, so we decided to spend our time refactoring the code to support the Oauth 1.0a/Oauth 2.0 call flows with the same base classes, as well as modularizing the whole implementation because one size just doesn't fit all. Now of course, you my dear don't even have to know any of the these details but just check out tynamo-federatedaccounts guide and open the gates for all of the Facebook and Twitter users to flock to your website
- [TYNAMO-92] - Twitter realm for federatedaccounts
[TYNAMO-120] - FallbackURL is no longer honored
You should upgrade.
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
- [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
- [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
- [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.
- [TYNAMO-97] - tynamo-exceptionpage doesn't handle operationexceptions
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.
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:
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
TYNAMO-74 - Support inline Facebook oauth permission screen
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!
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).
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.
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? With that suffering in mind, tynamo-federatedaccounts, a module for supporting remote authentication and merged (federated) authorization, was born.
I've been using various versions of more specialized implementations of the same concept before, but tynamo-federatedaccounts is the first attempt at generalizing Oauth & similar work flows to an easy-to-use package. The module is based on Tynamo's tapestry-security, a stable and well-maintained security package based on Apache Shiro for Tapestry5 applications. At this point, I'm looking for early user feedback for the current implementation and APIs. I've put together a simple, live demonstration to showcase it. Also check out the documentation for tynamo-federatedaccounts.
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, a high performing framework solves many other problems. Today, a typical, reasonably well-implemented Java web application on a modest hardware can serve hundreds of concurrent requests, thousands of concurrent users and tens of thousands of users a day from a single server. Most start-ups never need to worry about the scaling out problem until they actually have the money to pay for it. Unfortunately, you can also easily make the implementation horribly slow, suffering from scalability problems from the get-go and even more unfortunately, it's easier to go wrong with some Java frameworks than with others. For what Tapestry offers, the performance of the framework itself, both in terms of cpu and memory consumption is simply phenomenal. Performance matters.
However, I really don't want to make this post about Tapestry's performance. As soon as you mention one thing about a particular framework, people tend to place it in that category and forget about everything else. What I really like to give as an answer to people who ask why one should use Tapestry is this: because it is well-balanced and comprehensive. There are a lot of other web frameworks that are optimized with a certain thing in mind and in that narrow field, they typically beat the competition. It's difficult though to be a good all-around contender but that's exactly what Tapestry is all about. Tapestry doesn't force you to a certain development model - such as using sessions, always post, single url, ajax-only, thick RIA etc. If you just need to handle a specific case, such as building a single-page, desktop-like application for web, you could pick GWT, Flex or Vaadin, but if you are a building a generic, mixed static/dynamic content site with multiple pages you'd undoubtedly pick entirely different set of tools. Tapestry though, is an "enabling" technology - you could use it together with all three aforementioned RIA frameworks. You could also use and people have used Tapestry-IoC alone in non-web desktop applications. Not a whole lot of other "web" frameworks can claim suitability for such diverse use cases. Sadly, comprehensiveness of a framework can be a somewhat difficult area to objectively compare so each framework usually resorts to toting their best features to prove their superiority over others.
One criteria I personally use a lot in comparing effectiveness of competing solutions is their expressiveness and succinctness. Now, everybody knows that Java is a butt-ugly language (though it makes up on other departments, like performance and comprehensiveness). Today's Java is far from your grandfather's Java a few years back and Tapestry makes the best use of the more advanced, modern JVM techniques available today, such as bytecode manipulation, annotation-based meta programming and introspection without reflection. Tapestry code is purposefully remarkably succinct. Minimal effort required for creating Tapestry components makes it easy to refactor your application logic into reusable elements, rather than having to repeat yourself. Patterns in object-oriented languages are a well studied and accepted principle, but only a few (IoC) frameworks besides Tapestry IoC manages to have a framework level support for implementing common ones, such as chain of command, strategy and pipelines.
For Tynamo, I've said it before but I just don't think we could have achieved the same CRUD functionality with any other framework. Certainly anything can be done, but the cost of it would have both been far higher and we would have needed to build much more infrastructure. When we moved from Tapestry 4 to Tapestry 5 (and from Trails to Tynamo), it was amazing to see how we were able to simplify our implementation and remove huge amounts of code while keeping the concept unchanged and making it all more modular at the same time. Using a different stack, you could probably get closest to what tapestry-model is with a combination of Wicket and Spring, but allowing the same level of extensibility would undoubtedly be more cumbersome. Back in Trails, we actually had one person working on a pure Spring (MVC + core) implementation of the same concept but it died a slow death. As the documentation states, tapestry-model produced "default model is highly customizable, you can change pretty much anything you need, and make the changes specific to type, page or instance - a feature that very few other CRUD frameworks offer". The big difference is that when you need to customize the model, you don't have to rewrite it all, you'll be just customizing the pages and overriding components as needed.
Perhaps we've gone a bit overboard with modularity, but since it's just that simple with Tapestry, most of our modules are independently usable but seamlessly work together in the same web application as soon as you add them to the classpath. Today, Tynamo is much more than just tapestry-model, the CRUD framework. Tapestry-security, tapestry-conversations and tapestry-resteasy are all steadily gaining popularity and based on the page views, it seems that tapestry-security is poised to become our most popular module offering at some point. On that note, I have a few new supplemental modules for tapestry-security coming up which should be of interest to others as well, but more on that in a separate post. For now, I hope I've been able to give some answers to why at Tynamo, we think we've made the right choice with Tapestry and I'm confident that 2011 will be the best year yet both for Tapestry and Tynamo!