[Ur] Unsafe GET and slow message passing

[Ziv Scully]

(1) Makes sense :).

(2) Additional datum: I have this problem with both PostgreSQL (9.3) and
SQLite, so it's unlikely to be database specific.


On Saturday, August 29, 2015, Adam Chlipala <adamc at csail.mit.edu> wrote:

> On 08/29/2015 01:16 AM, Ziv Scully wrote:
>
>> (1) Say that [handler : unit -> transaction page] makes a write to a
>> database. Normally we can't just use [handler] as a link without a
>> [safeGet] in the relevant .urp file. However without exposing [handler] in
>> the .urs file or adding the [safeGet], we can do
>> [<form><submit={handler}></form>]. This makes [handler] accessible by
>> simply typing in a URL, even if it has destructive effects, because the
>> form handler expects no fields. There's a simple workaround for now: add a
>> [<hidden{#Dummy}/>] to the form (and change the type of [handler]
>> accordingly).
>>
>
> This is the easier of the two to respond to. :)
>
> The behavior you report is expected.  The general Ur/Web model is:
> (1) The language and implementation help you enforce important invariants,
> for security or otherwise.
> (2) However, the model is still that any page handler could be called with
> any arguments (and any applicable HTTP verb!) at any time.  The "side
> effects must use PUT" rule is only enforced for user interaction sequences
> that follow the normal control flow of your application, with no
> "protection" against wise guys who craft their own URLs.  IMO, you should
> make sure that a user calling a URL "out of order" may be able to break his
> own state, in a relatively benign way, but not break anyone else's state.
>
> (2) Sometimes doing "many" (order of 6) channel operations slows down the
>> server considerably, causing all requests to stall for a bit. The stall
>> isn't permanent, but often after the stall resolves, some small subset of
>> the messages don't make it to their recipients. The clients who missed
>> messages might still receive future messages but will never receive the
>> ones they missed. I found that something similar occurs with the official
>> Chat demo (try joining the same channel in ~8 tabs in quick succession), so
>> I don't think the issue is specific to my app. Has anyone run into this
>> before? I messed with the .urp file a little bit but nothing helped.
>>
>
> Hm, I never noticed that before!  It may be a concurrency bug in the
> runtime system.  I'll look into it further.
>
> _______________________________________________
> Ur mailing list
> Ur at impredicative.com
> http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.impredicative.com/pipermail/ur/attachments/20150829/9d3fd5ed/attachment.html>