Proposed fix: crazy infinite loop w/ ft:continuation-id
Hi, I tried passing the continuation ID as a hidden form parameter, using ft:continuation-id>. Until now, I've always put continuation IDs in the URI, but in this application I really need to do it this way (and if I can get this to work right, I'm going to do it this way again in the future!). The problem is that after the continuation is resumed, the response to that request is generated by an internal redirect (via sendPage()) of the request, which is of course matched against the sitemap, but since the request still contains the continuation-id parameter, it hits on that matcher and re-invokes the continuation, and it's dj vu all over again, forever and ever, amen. So, (you smugly say :-), I should just move my continuation-id matcher to the end of the pipeline, so that it only matches if nothing else did. Well, the way I have designed the page flow in this app which I think is the Right Way, BTW absolutely depends on always matching on a continuation-id parameter in the flow-originating request, and having this in turn work in a sane manner. And there is absolutely no use whatsoever for the continuation-id parameter, once the continuation has been resumed. I don't think I should have to redesign my page flow to something worse, just to work around an onerous constraint on matching the continuation-id! :-) See below for an example scenario, representative of the sort of page flow I'm implementing. But first, the proposed fix: I've added this method to the oac.environment.Request interface: public void killContinuation(); In an HttpRequest, this sets a flag which causes getParameter(continuation-id) to return null. This is a workaround for the lack of a removeParameter() method in HttpServletRequest (the delegate). Now, over to the flowscript side of CForms... in Form.prototype.showForm(), after the call to sendPageAndWait(), I call cocoon.request.killContinuation(). Works like a charm. No more infinitous loopage! So, my questions: Is this a good fix? There isn't some better one that I am missing, is there? My fix might seem like hacky special-case-ism. But it also seems like adding a general removeParameter() method to these wrappers, while certainly possible (it'd just be a HashSet), would be overkill to solve a general problem that doesn't really exist (after all there is a reason that HttpServletRequest has gotten along nicely all this time without such a method). But maybe I'm wrong about that, and someone will tell my why I really should add this as a removeParameter() method... WDYT? I've prototyped this in the v2 version of Form, but I'll add it to v1 and v3 before submitting a patch. -=-=-=--= A simple example of why I need this: Suppose we are doing lightweight authentication i.e., using pure flowscript, w/o the AuthFW. This is super-simple, but to break it way down in excruciating detail: 1) The user requests a protected resource /foo. 2) The sitemap dispatches to a flowscript controller function that handles this request 3) Since this is a protected resource, the controller calls a flowscript authorize() function 3) The user isn't logged in, so authorize() invokes a login form (a CForms form). (N.B.: the browser is not redirected to the login page. The address bar shows /foo). 3) The users fills out and submits the form, which is a form action=> so it requests /foo again, this time with some (additional?) POST parameters: userName, password, and continuation-id. 4) The continuation matcher in the sitemap hits, and the continuation is resumed. 5) The login was successful, so the authorize() function returns (otherwise, it just loops and reissues the login form, i.e. return == success). 6) The caller of of authorize() proceeds and generates the reply to the request for /foo. 7) The browser receives the reply and renders the page. The address bar shows /foo, the resource that was originally requested. Notes: (3) is the essential reason why I need this change. If /foo is requested with a continuation-id POST parameter, the continuation must be resumed. (7) Has important implications. I say the address bar shows '/foo', but what I really mean is that /foo was the URI in the reply. We may not care what the user sees in their address bar, but the other thing this controls is the browser's interpretation of relative links, and we may care very much about this! A side benefit of this more flow-oriented approach is that the application becomes a little more crisply responsive, since we're not issuing external redirects all over the place in order to get various pages rendered.
Re: Proposed fix: crazy infinite loop w/ ft:continuation-id
Mark Lundquist wrote: I tried passing the continuation ID as a hidden form parameter, using ft:continuation-id. Until now, I've always put continuation IDs in the URI, but in this application I really need to do it this way (and if I can get this to work right, I'm going to do it this way again in the future!). The problem is that after the continuation is resumed, the response to that request is generated by an internal redirect (via sendPage()) of the request, which is of course matched against the sitemap, but since the request still contains the continuation-id parameter, it hits on that matcher and re-invokes the continuation, and it's /dj vu/ all over again, forever and ever, amen. So, (you smugly say :-), I should just move my continuation-id matcher to the end of the pipeline, so that it only matches if nothing else did. Well, the way I have designed the page flow in this app which I think is the Right Way, BTW absolutely depends on always matching on a continuation-id parameter in the flow-originating request, and having this in turn work in a sane manner. And there is absolutely no use whatsoever for the continuation-id parameter, once the continuation has been resumed. I don't think I should have to redesign my page flow to something worse, just to work around an onerous constraint on matching the continuation-id! :-) See below for an example scenario, representative of the sort of page flow I'm implementing. But first, the proposed fix: I've added this method to the oac.environment.Request interface: public void killContinuation(); In an HttpRequest, this sets a flag which causes getParameter(continuation-id) to return null. This is a workaround for the lack of a removeParameter() method in HttpServletRequest (the delegate). Now, over to the flowscript side of CForms... in Form.prototype.showForm(), after the call to sendPageAndWait(), I call cocoon.request.killContinuation(). Works like a charm. No more infinitous loopage! So, my questions: Is this a good fix? There isn't some better one that I am missing, is there? No, it's horrible. My fix might seem like hacky special-case-ism. But it also seems like adding a general removeParameter() method to these wrappers, while certainly possible (it'd just be a HashSet), would be overkill to solve a general problem that doesn't really exist (after all there is a reason that HttpServletRequest has gotten along nicely all this time without such a method). But maybe I'm wrong about that, and someone will tell my why I really should add this as a removeParameter() method... WDYT? I've prototyped this in the v2 version of Form, but I'll add it to v1 and v3 before submitting a patch. -=-=-=--= A simple example of why I need this: Suppose we are doing lightweight authentication i.e., using pure flowscript, w/o the AuthFW. This is super-simple, but to break it way down in excruciating detail: 1) The user requests a protected resource /foo. 2) The sitemap dispatches to a flowscript controller function that handles this request 3) Since this is a protected resource, the controller calls a flowscript authorize() function 3) The user isn't logged in, so authorize() invokes a login form (a CForms form). (*N.B.:* the browser is /not/ redirected to the login page. The address bar shows /foo). 3) The users fills out and submits the form, which is a form action= so it requests /foo again, this time with some (additional?) POST parameters: userName, password, and continuation-id. 4) The continuation matcher in the sitemap hits, and the continuation is resumed. 5) The login was successful, so the authorize() function returns (otherwise, it just loops and reissues the login form, i.e. return == success). Note: flow function can not return. It can do sendPage,redirect - but it can't simply return. 6) The caller of of authorize() proceeds and generates the reply to the request for /foo. 7) The browser receives the reply and renders the page. The address bar shows /foo, the resource that was originally requested. I see several possible ways of solving your issue without crazy hacks. * Move view rendering into the internal-only pipeline. That's how it (usually) should be with the flow. * If you don't like above, issue a redirect in the step (5) - you'll loose continuation ID parameter in the process. * Third option. The best approach to implement your login scenario is to write custom auth action. If user is authenticated, you return a map, sitemap shows the view (nested in the map:act). If he is not, you return null and sitemap shows the login form (you can use flow and forms there as it is now): map:act type=myauth map:match pattern=* !-- generate page here -- /map:match /map:act map:call function=login continuation-id={request-param:continuation}/ Vadim
Re: Proposed fix: crazy infinite loop w/ ft:continuation-id
This is how I work with hidden continuation ids since my form posts. You can select based upon the request:method - continuing only on POST: map:select type=oacl-simple map:parameter name=value value={request:method}/ map:when test=GET map:call function=functionName map:parameter name=searchType value={0} / /map:call /map:when map:when test=POST map:call continuation={request-param:continuation-id} / /map:when /map:select Regards, Eric Vadim Gritsenko wrote: Mark Lundquist wrote: I tried passing the continuation ID as a hidden form parameter, using ft:continuation-id. Until now, I've always put continuation IDs in the URI, but in this application I really need to do it this way (and if I can get this to work right, I'm going to do it this way again in the future!). The problem is that after the continuation is resumed, the response to that request is generated by an internal redirect (via sendPage()) of the request, which is of course matched against the sitemap, but since the request still contains the continuation-id parameter, it hits on that matcher and re-invokes the continuation, and it's /dj vu/ all over again, forever and ever, amen. So, (you smugly say :-), I should just move my continuation-id matcher to the end of the pipeline, so that it only matches if nothing else did. Well, the way I have designed the page flow in this app which I think is the Right Way, BTW absolutely depends on always matching on a continuation-id parameter in the flow-originating request, and having this in turn work in a sane manner. And there is absolutely no use whatsoever for the continuation-id parameter, once the continuation has been resumed. I don't think I should have to redesign my page flow to something worse, just to work around an onerous constraint on matching the continuation-id! :-) See below for an example scenario, representative of the sort of page flow I'm implementing. But first, the proposed fix: I've added this method to the oac.environment.Request interface: public void killContinuation(); In an HttpRequest, this sets a flag which causes getParameter(continuation-id) to return null. This is a workaround for the lack of a removeParameter() method in HttpServletRequest (the delegate). Now, over to the flowscript side of CForms... in Form.prototype.showForm(), after the call to sendPageAndWait(), I call cocoon.request.killContinuation(). Works like a charm. No more infinitous loopage! So, my questions: Is this a good fix? There isn't some better one that I am missing, is there? No, it's horrible. My fix might seem like hacky special-case-ism. But it also seems like adding a general removeParameter() method to these wrappers, while certainly possible (it'd just be a HashSet), would be overkill to solve a general problem that doesn't really exist (after all there is a reason that HttpServletRequest has gotten along nicely all this time without such a method). But maybe I'm wrong about that, and someone will tell my why I really should add this as a removeParameter() method... WDYT? I've prototyped this in the v2 version of Form, but I'll add it to v1 and v3 before submitting a patch. -=-=-=--= A simple example of why I need this: Suppose we are doing lightweight authentication i.e., using pure flowscript, w/o the AuthFW. This is super-simple, but to break it way down in excruciating detail: 1) The user requests a protected resource /foo. 2) The sitemap dispatches to a flowscript controller function that handles this request 3) Since this is a protected resource, the controller calls a flowscript authorize() function 3) The user isn't logged in, so authorize() invokes a login form (a CForms form). (*N.B.:* the browser is /not/ redirected to the login page. The address bar shows /foo). 3) The users fills out and submits the form, which is a form action= so it requests /foo again, this time with some (additional?) POST parameters: userName, password, and continuation-id. 4) The continuation matcher in the sitemap hits, and the continuation is resumed. 5) The login was successful, so the authorize() function returns (otherwise, it just loops and reissues the login form, i.e. return == success). Note: flow function can not return. It can do sendPage,redirect - but it can't simply return. 6) The caller of of authorize() proceeds and generates the reply to the request for /foo. 7) The browser receives the reply and renders the page. The address bar shows /foo, the resource that was originally requested. I see several possible ways of solving your issue without crazy hacks. * Move view rendering into the internal-only pipeline. That's how it (usually) should be with the flow. * If you don't like
Re: Proposed fix: crazy infinite loop w/ ft:continuation-id
Hi, I saw that approach in the samples, but thought it would be nice to be able to navigate the site passing parameters with POST sometimes, so instead I came up with this: map match ... map:select type=request-parameter map:parameter name=parameter-name value=continuation-id/ map:when test={request-param:continuation-id} map:call continuation={request-param:continuation-id}/ /map:when map:otherwise map:call function... If the continuation parameter is not present, the test returns null, and goes to otherwise, which calls the form handler. If the parameter exists (regardless of whether GET/POST) it calls the continuation. Just a thought... Ben Pope. Eric E. Meyer wrote: This is how I work with hidden continuation ids since my form posts. You can select based upon the request:method - continuing only on POST: map:select type=oacl-simple map:parameter name=value value={request:method}/ map:when test=GET map:call function=functionName map:parameter name=searchType value={0} / /map:call /map:when map:when test=POST map:call continuation={request-param:continuation-id} / /map:when /map:select Regards, Eric