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 <[EMAIL PROTECTED]> 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: > [EMAIL PROTECTED] > For additional commands, e-mail: > [EMAIL PROTECTED] > > > -- 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
