Thus said Matt Welland on Mon, 05 Aug 2013 16:11:00 -0700: > Each person given access registers their public key (maybe an > administrator checks them in to an admin fossil similar to how > gitolite works) . Users do not have a fossil password (but they are > registered with the fossil). This might use or be similar to the CGI > REMOTE_USER variable workings.
In fact, this is precisely how it can be accomplished. The reason why it was failing for me before is because 127.0.0.1 is treated specially, so my initial test failed: fossil clone ssh://127.0.0.1//tmp/test.fossil new.fossil But, as long as the remote IP address is not 127.0.0.1, the script I sent works just like you would expect. fossil http finds that there is no user specified, it inspects the REMOTE_USER variable and uses that instead (as long as Accept REMOTE_USER is enabled in Access). Wow, this is really cool! Thanks for pointing me to REMOTE_USER. Now it is extremely easy to setup SSH access where the SSH key provides access to the fossil via the REMOTE_USER variable. And the end user doesn't need to even know their fossil username/password. Again, the script I used was: #!/bin/sh REMOTE_USER="$1" set -- $SSH_ORIGINAL_COMMAND while [ $# -gt 1 ]; do shift; done export REMOTE_USER exec /home/amb/bin/fossil http "$1" It would be better if I didn't have to rely on a script for this, which is why I thought a new fossil subcommand would be useful. This would mean all I have to put into my command="" is something like: command="/home/amb/bin/fossil sshgate user" ssh-rsa ... sshgate would then read the SSH_ORIGINAL_COMMAND, extract the path to the requested fossil file, set the REMOTE_USER variable to the user, and then exec() ``fossil http /path/to/fossil.fossil'' Andy -- TAI64 timestamp: 4000000052007ee5 _______________________________________________ fossil-users mailing list [email protected] http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
