Bug #6809

using f:link.action inside f:form breaks hmac verification

Added by Peter Niederlag over 5 years ago. Updated almost 5 years ago.

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?

fluidformViewHelper-hmacarguments-6809.diff Magnifier (2.1 kB) Peter Niederlag, 2010-03-12 14:14


Related issues

related to TYPO3.Fluid - Bug #6514: HMAC error when rendering links inside forms Resolved 2010-02-18
related to TYPO3.Fluid - Bug #6808: using f:link.action inside f:form breaks hmac verification Resolved 2010-03-12

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

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

Also available in: Atom PDF