On 07/29/2012 03:02 PM, Edward Z. Yang wrote:
Excerpts from Adam Chlipala's message of Sun Jul 29 12:37:26 -0400 2012:
Just exposing the environment variables literally doesn't sound so
appetizing: any [transaction] code would be able to read any environment
variable. There could be sensitive information in there, and it's nice
to be able to run other people's library code without worrying that it
can read sensitive information.
Ur/Web already supports a whitelist of HTTP headers that may be read by
transactions. What do you think of a directive that maps an environment
variable name in as a specific HTTP header? Then the existing mechanism
can do double-duty via a single whitelist.
Sure; whitelist would have been my second suggestion.
My one problem with overloading the HTTP header mechanism, is that while
request headers are arbitrarily controllable by users, environment variables
are not, and it's probably a good idea not to conflate the two.
OK. I think I'll go for a separate mechanism with exactly the same
interface.
Another idea would be to create an abstract "capability" type, where a
page handler may always request such a value as a function argument.
State-access functions like header/environment variable reading could
require a value of this type as an argument, so that a page handler
could call other functions without giving them direct access to touch
the request/response context.
So, I suppose what's not totally clear to me is why this isn't just the
reader monad?
As I understand it (based on zero personal experience), the reader monad
is about changing the type of your code, to indicate that it may read.
The capability mechanism instead determines "which code may read" based
on the contents of its variable environment, not the type of the code.
So, it's a lighter-weight mechanism in some sense.
_______________________________________________
Ur mailing list
[email protected]
http://www.impredicative.com/cgi-bin/mailman/listinfo/ur
