[Ur] Request environment variables

[Adam Chlipala]

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.