[Seaside] #disabled: + #callback:

[Sean Glazier]

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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/seaside/attachments/20170227/f795aa20/attachment-0001.html>