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.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
