Bug #6809

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

Added by Peter Niederlag almost 12 years ago. Updated over 11 years ago.

Status:
Resolved
Priority:
Must have
Category:
-
Target version:
-
Start date:
2010-03-12
Due date:
% Done:

100%

Estimated time:
Has patch:

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?


Files


Related issues

Related to TYPO3.Fluid - Bug #6808: using f:link.action inside f:form breaks hmac verificationResolved2010-03-12

Actions
Related to TYPO3.Fluid - Bug #6514: HMAC error when rendering links inside formsResolvedSebastian Kurfuerst2010-02-18

Actions
#1

Updated by Peter Niederlag almost 12 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?

#3

Updated by Sebastian Kurfuerst almost 12 years ago

  • Status changed from New to Accepted
  • Assignee set to Sebastian Kurfuerst
  • Priority changed from Should have to Must have
#4

Updated by Sebastian Kurfuerst almost 12 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