On October 18, 2010 at 08:02:15 PDT, Paolo Bolzoni wrote:
dear list,
I would like to use fossil as cgi program on a thttpd server.

The problem is that it seems fossil cannot connect to a server that requires authorization. This problem manifests only when using the command line, when I use fossil via web
browser it works fine.

In other words, when I browse (with firefox or elinks) this address it works fine:
http://name:p...@www.example.org/fossil/project1

when I use this command in my command line it does not:
fossil clone http://name:p...@www.example.org/fossil/project1 project1
fossil answers 401.

In other to use the authorization feature of thttpd I made a .htpasswd using htpasswd.

Sadly I don't believe fossil supports this.  The spec can be found at:

  http://tools.ietf.org/html/rfc2617

What I am doing wrong?
Thanks
Paolo

The way you have your thttpd server set up looks like this:

+------+   +--------+   +--------+
| user |<->| thttpd |<->| fossil |
+------+   +--------+   +--------+
               |            |
           +--------+   +--------+
           | RFC2617|   | fossil |
           |  Auth  |   |  user  |
           +--------+   |  auth  |
                        +--------+

Where "user" is one of:

1. A web browser
2. fossil doing a clone

In order to successfully access fossil, you must first get through thttpd by providing an RFC 2617 authentication.

Web browsers know how to do this just fine. The thttpd server sends back a 401 Authorization Required response which means to retry according to the returned www-authenticate header with a name and password (or hash thereof) encoded in an authorization header. (Organizations that support a single sign on mechanism often provide some kind of integration with this method of authorization.)

Now, after getting through the thttpd server you must get through the standard fossil login screen or clone authentication. If you have gone through the thttpd authorization and thttpd has set REMOTE_USER as a result, fossil can be told to bypass its own authorization and use the user value from REMOTE_USER (see RFC 3875 <http://tools.ietf.org/html/rfc3875 > -- you set this as "Allow REMOTE_USER authentication" on the fossil -> admin -> access page in the web gui only, it's not available via the command line fossil settings). It allows you to only have to authenticate once (to thttpd) instead of twice (to thttpd and to fossil).

When you try to clone you are not using a web browser. Instead the fossil executable that's trying to fetch a clone itself connects to thttpd and then gets a 401 response which it doesn't understand how to deal with and so never makes it through thttpd to talk to the remote fossil to begin the cloning process. So although the fossil executable accepts name and password (in the URL even) for clone, it does not know how to provide them to a web server (such as thttp) that is configured to require RFC 2617 authentication and furthermore, it's quite possible that the name and password used for the thttpd RFC 2617 authentication are different from the ones needed to satisfy the fossil user authentication. Currently the fossil clone command only accepts one set of user/password combination for cloning (the fossil user authentication ones -- which I believe it will pick up from the URL even though the name and password embedded in a URL are usually understood to be part of RFC 2617 authorization).

If you wish to retain your thttpd authentication for accessing the fossil web pages, you will need to provide access on another port or perhaps via ssh port forwarding or else configure the thttpd server to skip its authentication stage for incoming application/x-fossil content types (that's what the clone command uses).

Kyle
_______________________________________________
fossil-users mailing list
fossil-users@lists.fossil-scm.org
http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users

Reply via email to