Thus said Jan Nijtmans on Tue, 12 Nov 2013 16:52:57 +0100: > 2013/10/29 Jan Danielsson <jan.m.daniels...@gmail.com>: > > > Yes, very useful. We only use client certificates, and apache is > > set up to set REMOTE_USER from the client certificate, and fossil > > uses REMOTE_USER without authentication -- so the case where user > > passes password via the url is one which I had missed completely. > > I'll fix as this weekend or so. Thanks for trying/reporting! > > Password handling is fixed on trunk now, I merged it into your > "jan-httpsproxytunnel" branch too.
Is there a quick setup for HTTP proxy tunnel configurations? [Slightly OT response follows] Jan Danielsson brings up another scenario that might need addressing. If you want me to give it a look over with respect to the REMOTE_USER and client ceritificates, I can do so later on. I did test with client certificates, but not client certificates that are used for authenticating to Fossil using REMOTE_USER. Currently, Fossil will prompt for the password if a user is provided in the HTTPS URL, however, if you are using REMOTE_USER and PEER certificates, then it doesn't make sense to even specify a user in the URL. Would it be safe to assume that we should disable password prompting if --ssl-identity is provided? For example, this will obviously not prompt for a password: fossil clone --ssl-identity=id.pem https://remote/ clone.fossil But this currently will: fossil clone --ssl-identity=id.pem https://user@remote/ clone.fossil Should we disable prompting if --ssl-identity is provided? Thanks, Andy -- TAI64 timestamp: 4000000052827365 _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
