Bug #6809
using f:link.action inside f:form breaks hmac verification
Status: | Resolved | Start date: | 2010-03-12 | |
---|---|---|---|---|
Priority: | Must have | Due date: | ||
Assigned To: | Sebastian Kurfuerst | % Done: | 100% |
|
Category: | - | |||
Target version: | - | |||
Has patch: | Affected Flow version: |
Description
It seems impossible to link to another Page/Controller/Action/Plugin with f:link.action inside a f:form.
Test-Template:
<f:form controller="Mycontroller" action="myaction" name="newObject" object="{newObject}"> <!-- if we don't use a property of newObject the error is not triggered --> <f:form.textbox property="foo" /> <f:form.submit name="mySubmit" value="Submit" /> <!-- adding a link.action inside form with an Object triggers an "hmac could not be verified" error --> <!-- for some reason 'action' is dropped in RequestHashService->generateRequestHash() --> <!-- this happens only when we use a property of newObject --> <f:if condition="true"> <f:link.action action="baz" pluginName="pi3" controller="foobar" pageUid="14">Link to somewhere else</f:link.action> </f:if> </f:form>
Probably that's due to the fact that the Plugin (pix) seems not to be taken into account, when generating the hmac/Requesthash?
Related issues
History
#1 Updated by Peter Niederlag over 5 years ago
This is probably related to the fact that Tx_Fluid_ViewHelpers_FormViewHelper uses '$this->controllerContext->getUriBuilder()->getLastArguments()'.
But now, since we a had another call on the UriBuilder in between (by using a f:link ViewHelper) this does not quite return the arguments as used on f:form itself.
Now on, what would be a way to fix that?
#2 Updated by Peter Niederlag over 5 years ago
- File fluidformViewHelper-hmacarguments-6809.diff
added
and here is a patch. :->
#3 Updated by Sebastian Kurfuerst over 5 years ago
- Status changed from New to Accepted
- Assigned To set to Sebastian Kurfuerst
- Priority changed from Should have to Must have
#4 Updated by Sebastian Kurfuerst over 5 years ago
- Status changed from Accepted to Resolved
- % Done changed from 0 to 100
- Branch set to v4
Thanks for reporting, this issue has been solved because of Peter Niederlag's patch in r2049.
Greets, Sebastian