Finally found the time to work a little on implementing the "backend"
command that I proposed a few weeks ago. Please find a patch attached.
I've chosen a rather minimal approach. Also, it currently only does the
http
version.
fossil backend [-P port|pipe] [-F front-server-ip] [repository]
Fossil
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
On 2 June 2010 18:11, Joshua Paine 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 pr
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?
--
Joshua Paine
LetterBlock: Web applications built with joy
http://letterblock.com/
301-576-1920
___
On Jun 2, 2010, at 05:00, June 1, 2010 05:17:39 PDT, Richard Hipp wrote:
> [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
> l
DRH wrote:
> 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 "f
On Tue, Jun 1, 2010 at 7:19 AM, Paul Ruizendaal 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 st
>> Well, I'll try to review your patch next weekend and see where the
>> Windows issues might be.
I've had an early chance to look at your patch and to learn the SCGI
protocol. Please find my remarks below.
[1] Perhaps I'm thick as a brick, but my understanding of the SCGI
protocol is that it doe
SCGI is so simple that its pretty much impossible to implement wrongly.
The only brokenness that I've seen is that nginx' SCGI handler (Which is a
somewhat unmaintained 3rd party module) doesn't accept status: lines like
its supposed to. The work around took one line, however. If I ever get
around
> The biggest issue with HTTP 1.1 for backend communication is long
> running connections since HTTP doesn't support interleaving.
Now that I find a convincing argument!
Can you confirm from your experience that SCGI is not broken in this
respect in the same way as FastCGI (i.e. the protocol spe
On 31 May 2010 15:01, Paul Ruizendaal wrote:
>
> >> I'm really short on time right now, but I will try to help you in
> making
> >> this a cross-platform patch. I can test on WinXP, Linux and FreeBSD.
> Can
> >> you test on OS-X?
> >
> > No, sorry. I can add OpenSolaris to the testing platforms t
For those so interested, the modification is now being self hosted. See
http://fossil.e43.eu/fossil/. Anonymous cloning is allowed.
- Owen.
___
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/li
On 31 May 2010 07:49, Paul Ruizendaal wrote:
> Hi folks,
>
> Two remarks:
>
> 1. I'm happy that more and more people are contributing to Fossil, but I'm
> also a bit concerned about the increasing Posix dependence. The https code
> builds in a dependence on libssl, and now the below patch is Posi
Hi folks,
Two remarks:
1. I'm happy that more and more people are contributing to Fossil, but I'm
also a bit concerned about the increasing Posix dependence. The https code
builds in a dependence on libssl, and now the below patch is Posix only.
The cross-platform nature of Fossil is important to
I've finished modifying Fossil to support SCGI. Some notes:
- I rewrote the accept loop of the server/ui command at the same time. It
no longer uses select with a timeout in order to reap child processes;
instead, a signal handler is installed for SIGCHLD in order to reap them and
main
On May 29, 2010 18:59:30 PDT, Richard Hipp wrote:
> If I had a web server at hand that would do SCGI, I might consider
> adding the "fossil scgi" command for you. But as I don't; I have no
> way to test the "fossil scgi" command.
FYI, mod_scgi provides SCGI support in Apache. The sources ar
16 matches
Mail list logo
