[web-devel] [Yesod] Re: Next version of WAI: cleaning house

[Greg Weber]

Michael,

I agree that you are theoretically correct not to include extra info for
example about approot. On the other hand, when someone comes from using
Rails we have to explain to them this theory about why they have to
manually enter approot and can't tell if their app is over https, but they
will still scratch their head since in Rails that information was always
readily available. So I am wondering if there is a middle ground to be
found where being theoretically correct doesn't mean zero programmer
convenience.

But perhaps this has nothing to do with the WAI standard and should be
handled by middleware?


On Wed, Jul 24, 2013 at 5:23 AM, Michael Snoyman <michael at snoyman.com>wrote:

>
>
>
> On Wed, Jul 24, 2013 at 3:08 PM, Kazu Yamamoto <kazu at iij.ad.jp> wrote:
>
>> Michael,
>>
>> > I'm definitely not talking about removing the peer information. Request
>> has
>> > a remoteHost field which is of type SockAddr, and therefore provides
>> both
>> > remote IP address and port number (the latter, as you mention, being
>> mostly
>> > useless).
>>
>> Please understand that I'm not opposing your opinion. I'm just trying
>> to interpret user's opinions.
>>
>>
> I appreciate the input, I just wanted to clarify my proposal.
>
>
>>  > I'm not sure what you mean by telling if communication is encrypted
>> using
>> > the headers + IP address, can you clarify?
>>
>> Suppose a Yesod application receives X-Forwarded-For:.
>>
>> A bad client can insert X-Forwarded-For:. But if an IP address is
>> provided and the application knows the IP address of the proxy, the
>> application can tell whether or not the IP address can be trusted.
>>
>> I'm not sure that there is a standard header field to tell HTTPS.
>> But if the proxy and the application shares such field:
>> - The application can truct the field according peer's IP address
>> - The application can tell the outside HTTP is encrypted
>>
>> Correct me if I misunderstand.
>>
>>
> I'd never considered checking the IP address of the proxy. When I've used
> X-Forwarded-For, I've always made sure to set up a firewall to ensure the
> *only* connections come from the reverse proxy, and then x-forwarded-for
> can be trusted.
>
> As far as determining secure/insecure, it seems like Amazon's ELB sets
> x-forwarded-proto[1]. Not sure if that's a well accepted standard, but it
> seems useful.
>
> Michael
>
> [1]
> http://docs.aws.amazon.com/ElasticLoadBalancing/latest/DeveloperGuide/TerminologyandKeyConcepts.html#x-forwarded-proto
>
> _______________________________________________
> web-devel mailing list
> web-devel at haskell.org
> http://www.haskell.org/mailman/listinfo/web-devel
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/web-devel/attachments/20130724/4337847c/attachment.htm>