Basic rules
1) client has always access to what is on his side
2) never trust what client is sending you. If it's an id, check it's valid.
For the component id, JSF des this check for you. For the component
values send by client (components accepting input) , you must have
validators to do this.
For the action, in jsf, it's always the client telling server what
button (using id) has been pressed. So if you fear user change the
action of a button, he can only change the id of button. If it does not
correspond to an existing id inside the jsf component tree for the form,
nothing happens.
example: client is telling 'i clicked on button
form0:carList:row25:removeButton' The fact it corresponds to
#{currentRow.removeMe} method binding is all server side. JSF just
forward the event to form0 which forward to carList (datatable) which
does iteration to row25 and forward to child component removeButton.
As someone suggested, check with a proxy what is sent by client.
Kevin Galligan a écrit :
> I've been wondering something for a little while now. Some of the
> crud style links in my app use 'h:commandLink', with
> 't:updateActionListener' to set the particular element id value for
> that page. In days past I'd put the id on the query string, so like ...
>
> /app/DetailPage.do?itemId=1234
>
> Now, obviously, you had to be careful because somebody could change
> the id value manually. With JSF, using t:updateActionListener, can
> somebody change the id value sent? If I'm 100% sure they couldn't, I
> could relax the access checking a little.
>
> Most of these links are in t:dataTable's, with
> preserveDataModel="true". If state is kept on the server, or
> encrypted on client (I think you can do that, right?), do I have to
> worry about the user getting access to something they shouldn't?
>
> Thanks in advance,
> -Kevin
