Have thought about it some more, but no security epiphany. My view remains that the command should be something like this:
fossil backend http|scgi [-P port|pipe] [-F front-server-ip] [-R repository] Semantics could be: - all requests coming from a client other than the front-server-ip (fip) are denied with a "403 forbidden" response. - all requests that specify a real client ip of 127.0.0.1 are denied with the same response - For http, X-Forwarded-For only looks at the first (ultimate client) ip; if ommitted the fip is used - For http, it sets the base url to X-Fossil-BaseUrl; if ommitted the base url is root - For scgi, the client ip is set to the client ip header which must be present (at penalty of "400 bad request") - For both, REMOTE_USER is honoured Variations could be to add "any" to http|scgi to serve both at the same time, or to make acceptance of remote user a feature that must be enabled with an additonal flag. I think & hope that the above can be done in a small patch, a I remain opposed to adding bloat to Fossil. Will that work for security and convience? Input welcome. Paul On Wed, 2 Jun 2010 23:27:57 +0100, Owen Shepherd <owen.sheph...@e43.eu> wrote: > On 2 June 2010 18:11, Joshua Paine <jos...@letterblock.com> wrote: > >> Only 127.0.0.1 is privileged, right? So can we just not trust >> X-Forwarded-For: 127.0.0.1 no matter who says it, and not worry if >> X-Forwarded-For is abused otherwise? >> > > No. Fossil keys its login cookies off the user's IP address. If the > user can provide X-Forwarded-For, then stealing a cookie becomes a > lot more useful. fossil backend http|scgi [-P port|pipe] [-F front-server-ip] [-R repository] _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
