You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by Jeremy <jk...@jkassis.com> on 2005/08/10 08:02:42 UTC
4.0: HTTP / HTTPS Protocol Switching
I'm submitting a patch to enable HTTP / HTTPS protocol switching that comes
on the heels of a couple of days of research. Hope you dig it! Here's the
background on why and what I did:
1. First, I tried to get the container do it. Unfortunately, Tomcat is
good about getting you into HTTPS using a <security-constraint>, but not
out. There's no way to specify that a resource / page *must* be accessed
with HTTP.
2. So, I setup redirects in Tapestry. I added a property to my BasePage
(BasePage.secure) that indicates whether or not the page should be accessed
with HTTPS. Then in the BasePage.pageValidate method, I throw a redirect to
switch the protocol from http > https OR https > http as necessary. This
works, but if a listener method in PAGE-A (set for http access) uses the
RequestCycle to activate PAGE-B (set for http access), then the pageValidate
method of PAGE-B throws a redirect to switch back to HTTP, the browser makes
a request for PAGE-A again using http, and the app's caught in an infinite
redirect loop.
3. So, I setup the BasePage.pageValidate to just allow access when
https is used. But now the app has the same problem it had when I had
redirects working in tomcat: it can't get back to http.
4. So, I created a new ILinkRenderer that grabs the page name from its
underlying ILink, uses a PageSpecificationResolver to grab the page
specification, check for the declaration of BasePage.secure, and call
getAbsoluteUrl of the underlying ILink as necessary to output an HTTP or
HTTPS link. It works pretty well. But it doesn't work for Forms, only for
AbstractLinkComponent and its descendents. And it's hard to grab the page
name from the ILink at this point in rendering - after the LinkFactoryImpl
applies ServiceEncoders that mess everything up.
5. At this point I decided to stop hacking around the issue and patch
the source. I gave EngineServiceLink two new parameters: _scheme and _port.
When a client calls EngineServiceLink.getUrl(), EngineServiceLink checks its
_scheme and _port properties. If _scheme is not specified or the same as the
scheme used to make the current request, getUrl() does exactly what it did
before: it returns a relative url. If _scheme is specified and not equal to
the scheme used to make the current request, getUrl() returns an absolute
URL with the specified scheme and port through its getAbsoluteUrl method.
Then I set up my engine services to check for the BasePage.secure property
(what the custom ILinkRenderer did before) and override the default scheme
and port for the link.
6. Of course, I updated all the references to
LinkFactoryImpl.constructUrl in the default engine services and tests.
Here's the patch:
Re: 4.0: HTTP / HTTPS Protocol Switching
Posted by Colin Sampaleanu <co...@exis.com>.
People interested in fairly powerful, declarative http/https protocol
switching might also look to using Acegi Security (aka Spring Security).
http://acegisecurity.sourceforge.net/
While it's also got a number of other really nice features, Acegi has
the ability to let you declare which parts of a site need to be SSL vs.
those that don't, with seamless switching back and forth. This is done
via a servlet filter.
With Tapestry 4 supporting friendly URLs out of the box, it's much more
realistic/easier to use something like Acegi Security with it.
--
Colin Sampaleanu
Interface21 Principal Consultant
Spring Training, Consulting and Support - "From the Source"
http://www.springframework.com
Howard Lewis Ship wrote:
>This might have made it into 4.0-beta-4 if it had been submitted as a
>JIRA issue. Submitting patches onto the mailing list just doesn't
>work ... nobody can keep up with the mailing list! Please add this to
>JIRA.
>
>On 8/10/05, Jeremy <jk...@jkassis.com> wrote:
>
>
>>
>>
>>
>>I'm submitting a patch to enable HTTP / HTTPS protocol switching that comes
>>on the heels of a couple of days of research. Hope you dig it! Here's the
>>background on why and what I did:
>>
>>
>>
>>First, I tried to get the container do it. Unfortunately, Tomcat is good
>>about getting you into HTTPS using a <security-constraint>, but not out.
>>There's no way to specify that a resource / page *must* be accessed with
>>HTTP.
>>So, I setup redirects in Tapestry. I added a property to my BasePage
>>(BasePage.secure) that indicates whether or not the page should be accessed
>>with HTTPS. Then in the BasePage.pageValidate method, I throw a redirect to
>>switch the protocol from http > https OR https > http as necessary. This
>>works, but if a listener method in PAGE-A (set for http access) uses the
>>RequestCycle to activate PAGE-B (set for http access), then the pageValidate
>>method of PAGE-B throws a redirect to switch back to HTTP, the browser makes
>>a request for PAGE-A again using http, and the app's caught in an infinite
>>redirect loop.
>>So, I setup the BasePage.pageValidate to just allow access when https is
>>used. But now the app has the same problem it had when I had redirects
>>working in tomcat: it can't get back to http.
>>So, I created a new ILinkRenderer that grabs the page name from its
>>underlying ILink, uses a PageSpecificationResolver to grab the page
>>specification, check for the declaration of BasePage.secure, and call
>>getAbsoluteUrl of the underlying ILink as necessary to output an HTTP or
>>HTTPS link. It works pretty well. But it doesn't work for Forms, only for
>>AbstractLinkComponent and its descendents. And it's hard to grab the page
>>name from the ILink at this point in rendering – after the LinkFactoryImpl
>>applies ServiceEncoders that mess everything up.
>>At this point I decided to stop hacking around the issue and patch the
>>source. I gave EngineServiceLink two new parameters: _scheme and _port. When
>>a client calls EngineServiceLink.getUrl(), EngineServiceLink checks its
>>_scheme and _port properties. If _scheme is not specified or the same as the
>>scheme used to make the current request, getUrl() does exactly what it did
>>before: it returns a relative url. If _scheme is specified and not equal to
>>the scheme used to make the current request, getUrl() returns an absolute
>>URL with the specified scheme and port through its getAbsoluteUrl method.
>>Then I set up my engine services to check for the BasePage.secure property
>>(what the custom ILinkRenderer did before) and override the default scheme
>>and port for the link.
>>Of course, I updated all the references to LinkFactoryImpl.constructUrl in
>>the default engine services and tests.
>>
>>
>>
>>Here's the patch:
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>
>>---------------------------------------------------------------------
>>To unsubscribe, e-mail:
>>tapestry-dev-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail:
>>tapestry-dev-help@jakarta.apache.org
>>
>>
>>
>>
>>
>
>
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org
Re: 4.0: HTTP / HTTPS Protocol Switching
Posted by Howard Lewis Ship <hl...@gmail.com>.
This might have made it into 4.0-beta-4 if it had been submitted as a
JIRA issue. Submitting patches onto the mailing list just doesn't
work ... nobody can keep up with the mailing list! Please add this to
JIRA.
On 8/10/05, Jeremy <jk...@jkassis.com> wrote:
>
>
>
> I'm submitting a patch to enable HTTP / HTTPS protocol switching that comes
> on the heels of a couple of days of research. Hope you dig it! Here's the
> background on why and what I did:
>
>
>
> First, I tried to get the container do it. Unfortunately, Tomcat is good
> about getting you into HTTPS using a <security-constraint>, but not out.
> There's no way to specify that a resource / page *must* be accessed with
> HTTP.
> So, I setup redirects in Tapestry. I added a property to my BasePage
> (BasePage.secure) that indicates whether or not the page should be accessed
> with HTTPS. Then in the BasePage.pageValidate method, I throw a redirect to
> switch the protocol from http > https OR https > http as necessary. This
> works, but if a listener method in PAGE-A (set for http access) uses the
> RequestCycle to activate PAGE-B (set for http access), then the pageValidate
> method of PAGE-B throws a redirect to switch back to HTTP, the browser makes
> a request for PAGE-A again using http, and the app's caught in an infinite
> redirect loop.
> So, I setup the BasePage.pageValidate to just allow access when https is
> used. But now the app has the same problem it had when I had redirects
> working in tomcat: it can't get back to http.
> So, I created a new ILinkRenderer that grabs the page name from its
> underlying ILink, uses a PageSpecificationResolver to grab the page
> specification, check for the declaration of BasePage.secure, and call
> getAbsoluteUrl of the underlying ILink as necessary to output an HTTP or
> HTTPS link. It works pretty well. But it doesn't work for Forms, only for
> AbstractLinkComponent and its descendents. And it's hard to grab the page
> name from the ILink at this point in rendering – after the LinkFactoryImpl
> applies ServiceEncoders that mess everything up.
> At this point I decided to stop hacking around the issue and patch the
> source. I gave EngineServiceLink two new parameters: _scheme and _port. When
> a client calls EngineServiceLink.getUrl(), EngineServiceLink checks its
> _scheme and _port properties. If _scheme is not specified or the same as the
> scheme used to make the current request, getUrl() does exactly what it did
> before: it returns a relative url. If _scheme is specified and not equal to
> the scheme used to make the current request, getUrl() returns an absolute
> URL with the specified scheme and port through its getAbsoluteUrl method.
> Then I set up my engine services to check for the BasePage.secure property
> (what the custom ILinkRenderer did before) and override the default scheme
> and port for the link.
> Of course, I updated all the references to LinkFactoryImpl.constructUrl in
> the default engine services and tests.
>
>
>
> Here's the patch:
>
>
>
>
>
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> tapestry-dev-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> tapestry-dev-help@jakarta.apache.org
>
>
>
--
Howard M. Lewis Ship
Independent J2EE / Open-Source Java Consultant
Creator, Jakarta Tapestry
Creator, Jakarta HiveMind
Professional Tapestry training, mentoring, support
and project work. http://howardlewisship.com
RE: 4.0: HTTP / HTTPS Protocol Switching
Posted by Jeremy <jk...@jkassis.com>.
Hi! Will this get included in the beta-4 release that's happening soon?
Many thanks!