[Seaside] #disabled: + #callback:

[Johan Brichau]

NEVER rely on client-side for security or related checks.
ALWAYS add server-side checks too.

If you want seaside to disable the callbacks on a disabled button, it will need still need to 
make a server call, which can also be intercepted/hacked. It would be a false sense of security. Of course, it might be handy but do not rely on it.

Cheers,
Johan

> On 27 Feb 2017, at 20:52, Sean Glazier <sglazier456 at gmail.com> wrote:
> 
> That works as well and is easier to do. the app I did we had to be much more anal about everything
> 
>  
> Kind Regards,
>  
> Sean Glazier
>  
> 
>> On Mon, Feb 27, 2017 at 2:15 PM, Sven Van Caekenberghe <sven at stfx.eu> wrote:
>> Hi Paul,
>> 
>> > On 27 Feb 2017, at 17:35, PAUL DEBRUICKER <pdebruic at gmail.com> wrote:
>> >
>> > Hi -
>> >
>> >
>> > If in a Seaside form (3.2.1 but not sure it matters) you have an input with a callback (& e.g #onChange: handler) and set its state to 'disabled' a nefarious actor can remove the 'disabled' state from the form element in the browser and then trigger the seaside callback on the form submit.
>> 
>> Well, I had a problem very close to that, that actually cost me real money !
>> 
>> In a shopping cart I used <A> tags that rendered as buttons (Bootstrap), disabling them when the user was not supposed to continue (as in not order for free from a far away country ;-). The continue button looked disabled, but it wasn't.
>> 
>> So I ended up doing
>> 
>> renderContinueOn: html
>>   | anchor |
>>   html space.
>>   (anchor := html anchor)
>>     class: 'btn btn-primary';
>>     disabled: self canContinue not.
>>   "since <A> cannot really be disabled, do not add a callback !"
>>   self canContinue ifTrue: [ anchor callback: [ ... ] ].
>>   anchor with: [ .. ]
>> 
>> It was of course my own fault, but it would be nice if calling disabled: false on a Seaside component had the effect of disabling callbacks as well.
>> 
>> Sven
>> 
>> > How do people usually handle this?
>> >
>> >
>> >
>> > Right now in critical places I have two sets of form-input-drawing code e.g.
>> >
>> > disable
>> >  ifTrue:[ html textInput
>> >               disabled: true;
>> >               value: self name ]
>> >  ifFalse:[ html textInput
>> >                 onChange: html jQuery ajax serializeThis;
>> >                 on: #name of: self].
>> >
>> > But in other places I am neglectful.
>> >
>> >
>> > It seems to me that if I moved the #disabled: send down to be the last thing sent to the input then I could modify the #disabled: method to wipe out the callback and any javascript handlers attached to the input, preventing the unlikely attack I mention above.
>> >
>> >
>> > Does that make sense?
>> >
>> >
>> > Thanks for any thoughts you care to share
>> >
>> >
>> > Paul
>> >
>> >
>> >
>> >
>> > _______________________________________________
>> > seaside mailing list
>> > seaside at lists.squeakfoundation.org
>> > http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
>> 
>> _______________________________________________
>> seaside mailing list
>> seaside at lists.squeakfoundation.org
>> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
> 
> _______________________________________________
> seaside mailing list
> seaside at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/cgi-bin/mailman/listinfo/seaside
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20170303/0a2c2e04/attachment-0001.html>