click-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Bob Schellink <sab...@gmail.com>
Subject Re: Request Parameter Autobinding
Date Sun, 21 Nov 2010 00:55:38 GMT
Just a bit of history on binding. In Click 1.4 binding was introduced because people wanted
a
shortcut for binding and converting input params. This was in the Java 1.4 days, pre annotation.
So
public fields was used as binding. With Java 1.5 Bindable was introduced but backward compatibility
was kept in place. (If you want to use public fields in your pages that should not be bound,
you can
set autobinding="annotation" and public fields won't be touched.)

So the intention wasn't to support both public fields and @Bindable. It was for preserving
backwards
compatibility.

I understand the argument of splitting @Bindable into two behaviors -> @InputParameter
(which sets
and coerce the value vs @AddToModel which adds the value to the model. The Bindable design
also
raised these issues:

https://cwiki.apache.org/confluence/display/CLICK/Java+5+Support

but this work was never completed.

Kind regards

Bob

On 21/11/2010 01:49, Lorenzo Simionato wrote:
> On Nov 20, 2010, at 14:35 , Bob Schellink wrote:
> 
> Here what i meant is that if you declare a field as @Bindable you are clearly aware that
it can be set in some way by the user.
> If you have a public field (ok, it's rare) this is not that obvious.
> 
> Here the XSS was just an example. The fact that one can set a value that i intended only
for output is disturbing.
> As a couple of other examples:
> -suppose the welcomeMessage is the title of the page. It's not nice that one can put
an arbitrary title on the page, even if it is escaped properly.
> 
> -suppose one modifies the RequestTypeConverter as explained in the documentation to dynamically
load customers from the db.
> In a page one would like to do something with a customer object and then print the details,
so we could have something like:
> MyPage.class
> public class MyPage extends Page {
>    @Bindable protected Customer customer = loadCustomer(3);
> 
>     pubic void action() {
>          customer.set.....();
>     }
> 
> MyPage.html
> $customer.name
> 
> a different customer can be loaded with a request like mypage.htm?customer=56
> (this example is a little weird but is just to get the idea)
> 
> 
> These are just examples and maybe if all is handled very carefully by the programmer
there would not be any problems.
> However, they demonstrate that it is easy to make something that does not work as intended.
> As a last example consider SQL Injections: if you escape the input properly you do not
have the problem. On the other hand,
> to prevent the problem even if you are not that careful PHP has introduced magic quotes
and in Java we have preparedStatements (yes i'm simplifying a lot the things here!). The concept
is that this double role of public field and ones annotated with @Bindable (as parameters
and variables added to the page) it does not seem a good idea to me.
> 
> --
> Lorenzo


Mime
View raw message