Actually, not all types are serializable, but you're right that XML
currently is! This might call for more checking in the compiler for bad
type parameters of [serialize]/[deserialize]. Thanks for pointing it out.
On 11/03/2017 08:58 AM, Peter Brottveit Bock wrote:
I don't really see the injection problem in the case of ur/web, since there is
a strict separation between strings and xml. (I also just checked: it seems
one can't send xml from the client to the server—which is good in case of
malicious clients.)
I do see the problem with the javascript, though. Related to this, I was
surprised to learn yesterday that all types are serializeable. Given the
problem you just highlighted, this seems problematic!
Example code:
----------------------------
fun get_text () : transaction string =
return "hello world"
fun generate_page () : transaction xbody =
text <- source "";
return
<xml>
<hr/>
<dyn signal={
x <- signal text;
return <xml> {[x]} </xml>
}/>
<button value="click me"
onclick={fn _ => s <- rpc (get_text ()); set text s }
/>
</xml>
table t : { Elem : serialized xbody }
fun add_page () : transaction unit =
page <- generate_page ();
dml(INSERT INTO t(Elem) VALUES ({[serialize page]}))
fun main () : transaction page =
current_pages <-
queryX (SELECT * FROM t) (fn row => deserialize row.T.Elem);
return <xml>
<body>
<button value="add page"
onclick={fn _ => rpc (add_page ())}/>
<hr/>
{current_pages}
</body>
</xml>
----------------------------
Running this page, clicking on "add page", and then refreshing gives an error
in Firefox's developer console.
— Peter
On Fri, 3 Nov 2017, at 13:00, Adam Chlipala wrote:
On 11/02/2017 11:19 PM, Artyom Shalkhakov wrote:
2017-11-03 1:59 GMT+06:00 Peter Brottveit Bock <p...@peterbb.net
<mailto:p...@peterbb.net>>:
It seems to me that it's not possible to store xml in a database.
Is there any reason for this?
Storing it in a database is prone to XML/HTML injection (therefore the
general case is disallowed).
Right, that's true. However, it shouldn't be a concern when only your
Ur/Web app accesses that database.
Still, overnight I thought of another issue: legitimate JavaScript code
within HTML fragments can become illegitimate across versions of your
Ur/Web app! A global identifier may no longer exist, causing an
unbound-identifier exception when using HTML retrieved from the
database. To me, this is the kiss of death, reminding me why this
feature deserves to be left out.
_______________________________________________
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
_______________________________________________
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
_______________________________________________
Ur mailing list
Ur@impredicative.com
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
