[Ur] cookie + table compiler bug

[Adam Chlipala]

On 03/22/2013 06:04 PM, Nathan Wolfe wrote:
> When I compile the attached code (urweb -dbms sqlite -db 
> dbname=some.db some) I get a weird message which I assume is a bug in 
> the compiler:
>
> deStrcat
> e:  FFI(Basis.sigString({}))
> unhandled exception: Fail: Jscomp: deStrcat
>
> It appears to be related to both the cookie and the table, because if 
> either of them are removed it compiles fine.

Yup, you were right that (1) it was a bug and (2) it was triggered by 
the combination of reading a cookie and writing to a table.

Short reply: It's fixed now in the public Mercurial repo.

Longer reply: This was an issue having to do with the combination of two 
Ur/Web features:
     (A) Automatic protection against cross-site request forgery (CSRF) 
attacks, by including with each form a server-calculated cryptographic 
signature of the current cookie values
     (B) Finding commonly referenced JavaScript code and putting it in a 
static .js file to save on browser loading time

Unfortunately, (B) can't work easily on a fragment that needs to 
generate a form including a CSRF signature.  My change detects fragments 
that use signatures and blacklists them from being moved to the static 
.js file.

As to why it was important both to read a cookie and write a form: If a 
page handler doesn't read any cookies, then it isn't using any 
information not present in the URL or form fields that "the attacker" 
may have set up, so the attacker could just as well have made the same 
request directly with the same effect, so there's no need to do CSRF 
protection.  At the same time, if a page handler doesn't change any 
persistent state (e.g., write to the database), then not much harm can 
be done by tricking a user into visiting the page, so there's no need to 
do CSRF protection.