Major Description
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 <jkassis@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