Tapestry 5 features continue to come together rapidly; the latest is HTTPS support.
It's very simple: mark a page as secure ...
@Secure
public class ProcessOrder
{
. . .
}
... and Tapestry takes it from there. Every request for that page will automatially use an HTTPS protocol URL. Any attempt to circumvent HTTPS will result in an HTTPS redirect; there's no way to access the page without HTTPS. Links from a secure page to an insecure page use the standard "http" protocol ... so Tapestry handles the whole cycle, from insecure to secure and back again.
That's about it; behind a firewall there's a little bit more configuration to allow Tapestry to know how to properly build the complete URL (the URL with protocol, server name and maybe port) since (behind a firewall) the servlet API doesn't properly report the information the way the client web browser needs it.
That's neat. Be careful with naming though. There are several aspects to security: authentication, authorization, and privacy. Secure channel communications falls under privacy. It would be nice to support authorization through an annotation, as well.
ReplyDeleteWell, is is Secure as in Secure Sockets Layer. What comes after that is declarative requirements for necessary privileges ... we'll see if there's eventually a generic annotation for that, but it's a popular thing to build on top of Tapestry. I've done and annotation solution for Tapestry 4, and I'm assisting another Formos developer build one for Tapestry 5.
ReplyDeleteGreat feature. How will it work for pages that stay there, only updated div by div using Ajax ? Do you have plans to allow a login form for instance, to send an HTTPS request, then continue the work over plain HTTP ?
ReplyDeleteThis is awesome and something I had wanted in T4 for ages. My solution there a couple years back was to add mod_rewrite rules. Needless to say, this was a bit flimsy and took some debugging to work out.
ReplyDeleteThat's pretty schweet. I am wondering, though: My T4 application has a page that hides certain data if you access it via HTTP, and allows you to switch over to HTTPS to reveal it. A @Secure annotation wouldn't work for something like that. Are there other mechanisms for going secure that would allow behavior like the one I describe?
ReplyDeleteI decided to be a bit draconian, so I've deliberately not (for example) added a "secure" parameter to Form, or directly support your use case.
ReplyDeleteHowever, you can simulate it as two pages. The public page (with class and template) and a subclass that adds @Secure.
The template for the public page can include some conditional portions, based on the Request.isSecure() property.
The subclass will override the security, but inherit the logic and template.
The only issue is when the page has persistent properties; those would have to be converted to application state objects to be properly shared between the public and the secure versions of the page.
Great feature! I can vividly remember the pains I had to go though doing this with JSF ;-)
ReplyDeleteBut it seem that if a page is secure the urls are all absolute and loose their port nr. Is this configurable and if so how?
Joost
PS: I posted a question about this on the mailing list which didn't seem to have come through. Any ideas?
Different protocol means you need a full and complete URL with protocol, server and, optionally, port. Further, HTTP is typically on port 80 and HTTPS is typically on port 443. Check out the docs for the hook to override how Tapestry builds these protocol-spanning URLs.
ReplyDelete