On Tue, Jun 1, 2010 at 7:19 AM, Paul Ruizendaal <p...@planet.nl> wrote:
>
> [3] So, the cleanest solution may be the following. If you have
> "cgi_handle_http_request()" recognise whether it is reading a http or an
> scgi request (which is easy: an http request starts with an ascii letter
> and an scgi request starts with an ascii decimal digit) and make it handle
> both forms, you will have added SCGI support for all platforms.
>
> [4] This has the added advantage that no new command is needed: "fossil
> server" will do both http and scgi at the same time. You can add the unix
> domain socket code to the fossil server command if needed. The name of the
> "fossil http" command becomes a bit of a misnomer as it does more, but I
> don't think that this is a problem.
>
There are security implications to this. If "fossil http" accepts SCGI,
then someone running Fossil off of inetd/xinetd would allow anonymous users
to submit SCGI instead of HTTP. And with SCGI, you can send parameters such
REMOTE_USER that completely bypass the login mechanism.
But I think you are on the right track. The same routine that implements
"fossil server" could also implement "fossil scgi" and simple pass through
flags that cause cgi_handle_scgi_request() to be invoked instead of
cgi_handle_http_request(). It is not quite as clean and elegant as your
proposed solution, but it does have the advantage of prevent login
forgeries.
> [7] In the odd case that I actually convinced you that http proxying is a
> better solution than SCGI for integrating a fossil repo into a larger
> website, adding support for "X-Forwarded-For" is just a few extra lines of
> code in "cgi_init()":
>
> z = (char*)P("REMOTE_ADDR");
> if( z ) g.zIpAddr = mprintf("%s", z);
> + z = (char*)P("X_FORWARDED_FOR");
> + if( z ) g.zIpAddr = mprintf("%s", z);
>
Here again, we need to be mindful of security. Miscreants can easily forge
an x-forwarded-for: line in an HTTP request and in the default configuration
Fossil allows requests requests from 127.0.0.1 to bypass the login
mechanism. (That login bypass for 127.0.0.1 makes the "fossil ui" command
much more convenient.) So at the very least, we would want to check the
value supplied by x-forwarded-for and make sure it is not 127.0.0.1. In
addition, we might want to disregard x-forwarded-for completely unless the
real REMOTE_ADDR is 127.0.0.1, or perhaps some other well-known address
specified on the "fossil server" or "fossil http" command-line. In other
words, disregard x-forwarded-for unless the request is coming from a known
trusted host.
--
---------------------
D. Richard Hipp
d...@sqlite.org
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
