Jim Jagielski wrote:
Suggested patch:
Index: src/main/http_core.c =================================================================== RCS file: /home/cvs/apache-1.3/src/main/http_core.c,v retrieving revision 1.332 diff -u -u -r1.332 http_core.c --- src/main/http_core.c 29 Mar 2004 18:35:29 -0000 1.332 +++ src/main/http_core.c 14 Apr 2004 15:58:42 -0000
@@ -543,6 +546,32 @@ return conf->ap_auth_name; }
+API_EXPORT(const char *) ap_auth_nonce(request_rec *r) +{ + core_dir_config *conf; + conf = (core_dir_config *)ap_get_module_config(r->per_dir_config, + &core_module); + if (conf->ap_auth_nonce) + return conf->ap_auth_nonce; + + /* Ideally we'd want to mix in some per-directory style + * information; as we are likely to want to detect replay + * across those boundaries and some randomness. But that + * is harder due to the adhoc nature of .htaccess memory + * structures, restarts and forks. + * + * But then again - you should use AuthNonce in your config + * file if you care. So the adhoc value should do. + */ + return ap_psprintf(r->pool,"%lu%lu%lu%lu%lu%s", + *(unsigned long *)&((r->connection->local_addr).sin_addr ), + *(unsigned long *)ap_user_name, + *(unsigned long *)ap_listeners, + *(unsigned long *)ap_server_argv0, + *(unsigned long *)ap_pid_fname, + "WHAT_THE_HECK_GOES_HERE?");
Dirk's later patch got rid of extra "%s" in the format string, so zap the last "%s" as well as my lame "WHAT_THE_HECK_GOES_HERE?".
Anybody want to think about what happens if we're so unlucky that the ap_user_name or ap_pid_fname string with '\0' is smaller than sizeof(unsigned long) and just happens to be allocated at the end of a page? Unlikely, but still... Maybe those are supposed to be &ap_user_name, &ap_listeners, etc.?
