You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@tapestry.apache.org by "Howard M. Lewis Ship (JIRA)" <ta...@jakarta.apache.org> on 2005/10/26 18:57:58 UTC
[jira] Closed: (TAPESTRY-580) Form, PageLink, DirectLink, etc. should support a scheme parameter for controlling the scheme of the generated URL
[ http://issues.apache.org/jira/browse/TAPESTRY-580?page=all ]
Howard M. Lewis Ship closed TAPESTRY-580:
-----------------------------------------
Fix Version: 4.0
Resolution: Fixed
> Form, PageLink, DirectLink, etc. should support a scheme parameter for controlling the scheme of the generated URL
> ------------------------------------------------------------------------------------------------------------------
>
> Key: TAPESTRY-580
> URL: http://issues.apache.org/jira/browse/TAPESTRY-580
> Project: Tapestry
> Type: Improvement
> Components: Framework
> Versions: 4.0
> Reporter: Jeremy F. Kassis
> Assignee: Howard M. Lewis Ship
> Fix For: 4.0
> Attachments: patch.txt, patch.txt
>
> 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
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: tapestry-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: tapestry-dev-help@jakarta.apache.org