click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Bob Schellink (JIRA)" <j...@apache.org>
Subject [jira] Updated: (CLK-685) Deprecate AbstractLink parameters binding - binding link parameters can lead to leaking parameters, especially for Ajax requests.
Date Wed, 30 Jun 2010 13:57:50 GMT

     [ https://issues.apache.org/jira/browse/CLK-685?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]

Bob Schellink updated CLK-685:
------------------------------

        Summary: Deprecate AbstractLink parameters binding - binding link parameters can lead
to leaking parameters, especially for Ajax requests.  (was: Links should be able to restrict
parameter binding for Ajax requests)
    Description: 
AbstractLink binds all incoming request parameters to its own parameter map. This makes the
link quite easy to use but has the potential to leak parameters which isn't targeted at the
link. It also duplicates the parameters already present on the Context.

The problem becomes obvious when using Ajax to invoke a link. Any extra parameters passed
for the Ajax request will be added to the link parameter map.

It is not common for applications to use link.getParameter and with the above mentioned issues
I suggest we remove getParameter, getParameterValues and getParameters from AbstractLink.
Click won't bind incoming request parameters to the link. However it will still be possible
to set link parameters and render them.

See http://click.1134972.n2.nabble.com/AbstractLink-request-parameter-leak-tp5139164p5139164.html
for more details.

  was:
AbstractLink binds all incoming request parameters to its own parameter map. This makes the
link quite easy to use but has the potential to leak parameters which isn't targeted at the
link.

The problem becomes obvious when using Ajax to invoke a link. Any extra parameters passed
for the Ajax request will be added to the link parameter map. We need to introduce a "strict"
parameter binding strategy for links so that only those parameters that was defined *before*
the processing event should be bound. The "strict" policy can be set to "on" for Ajax and
"off" for normal requests.

See http://click.1134972.n2.nabble.com/AbstractLink-request-parameter-leak-tp5139164p5139164.html
for more details.


I've reverted the strictParameterBinding option and instead deprecated AbtractLink getParameter,
getParameters and getParameterValues

> Deprecate AbstractLink parameters binding - binding link parameters can lead to leaking
parameters, especially for Ajax requests.
> ---------------------------------------------------------------------------------------------------------------------------------
>
>                 Key: CLK-685
>                 URL: https://issues.apache.org/jira/browse/CLK-685
>             Project: Click
>          Issue Type: Sub-task
>          Components: core
>    Affects Versions: 2.2.0
>            Reporter: Bob Schellink
>            Assignee: Bob Schellink
>             Fix For: 2.3.0-M1
>
>
> AbstractLink binds all incoming request parameters to its own parameter map. This makes
the link quite easy to use but has the potential to leak parameters which isn't targeted at
the link. It also duplicates the parameters already present on the Context.
> The problem becomes obvious when using Ajax to invoke a link. Any extra parameters passed
for the Ajax request will be added to the link parameter map.
> It is not common for applications to use link.getParameter and with the above mentioned
issues I suggest we remove getParameter, getParameterValues and getParameters from AbstractLink.
Click won't bind incoming request parameters to the link. However it will still be possible
to set link parameters and render them.
> See http://click.1134972.n2.nabble.com/AbstractLink-request-parameter-leak-tp5139164p5139164.html
for more details.

-- 
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.


Mime
View raw message