William Strecker-Kellogg <willsk@xxxxxxx> writes: > The http-backend looks at $REMOTE_USER and sets $GIT_COMMITTER_NAME to > that for use in the hooks. At our site we have a third party > authentication module for our proxy (Shibboleth) which sets an alternative > environment variable that our backend sees instead of REMOTE USER. > > This patch adds the config option http.remoteuser which changes what > environment variable is inspected by the http-backend code (it defaults > to REMOTE_USER). What is the chain of systems that pass the authenticated ident down to this CGI program? Can another part of that chain stuff the value of SHIBBOLETH_USER (or whatever) to REMOTE_USER before running it? As a design, I am not convinced this is a good change. What if the next person wants to interoperate with an authentication system that passes the same information via a mechanism different from environment variables? This change does not help him at all, as it is still married to "the information has to come from an environment variable" limitation. What if an authentication system can supply more appropriate committer ident information other than just the uesrname part? If it were a patch to teach the CGI program a new command line parameter, e.g. --log-as="C O Mitter <committer@xxxxxxxxxx>", it may have made a lot more sense, though. -- To unsubscribe from this list: send the line "unsubscribe git" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html