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