Custom Query (2296 matches)
Results (31 - 33 of 2296)
| Ticket | Resolution | Summary | Owner | Reporter |
|---|---|---|---|---|
| #50 | fixed | Basic Auth does not seem to work with SHA1 hashs | ||
| Description |
We are using Basic Authentication to protect part of our site. Initially, we set up the passwords using the SHA1 option. However, authentication failed. Using MD5 worked OK. I think NGINX module is not generating the SHA1 version of the password from the HTTP header correctly. This is the log dump: 2011/11/04 14:01:22 [debug] 26969#0: *6 rc: 0 user: "SR*" salt: "{SHA}VAf27VQjI3EG7889p+LAY9HqMOo=" 2011/11/04 14:01:22 [debug] 26969#0: *6 encrypted: "{SgJ8nAZK5bVg" 2011/11/04 14:01:22 [error] 26969#0: *6 user "istewartson": password mismatch, client: 62.73.161.20, server: site400.the clubuk.com, request: "GET /guides/index.html HTTP/1.1", host: "SR", referrer: "http://**SR**/report/chapter-1.html" Looking at the source, we think the code in src/core/ngx_crypt.c in the function ngx_crypt_ssha not creating the hashed version of the password correctly - it should be {SHA}followed by 20 characters - the encrypted line in the above debug dump looks wrong. I've remove some sensitive data and replaced it by SR (host and user names). |
|||
| #51 | fixed | nginx cache file md5 collision | ||
| Description |
The url : http://www.ads119.com/player/nanrenbang/nanrenbang-38212-93019-1234567890-8.html and http://www.ads119.com/player/nanrenbang/nanrenbang-38212-93019-1234567890-4.html have the same cache file. In the debug error log: 2011/11/10 13:10:06 [crit] 4475#0: *73 cache file "/home2/cache2/2/9c/439320ddec62f770fbc2eaca73c659c2" has md5 collision, client: 116.226.65.23, server: www.ads119.com, request: "GET /player/nanrenbang/nanrenbang-38212-93019-1234567890-8.html HTTP/1.1", host: "www.ads119.com:8080" [root@www logs]# head -n 2 /home2/cache2/2/9c/439320ddec62f770fbc2eaca73c659c2 | tail -n 1 KEY: http://www.ads119.com/player/nanrenbang/nanrenbang-38212-93019-1234567890-8.html [root@www logs]# head -n 1 /home2/cache2/2/9c/439320ddec62f770fbc2eaca73c659c2 | hexdump 0000000 86df 4ebb 0000 0000 3fca 4eba 0000 0000 0000010 5caf 4ebb 0000 0000 7226 0786 0000 007f 0000020 015b 5820 5448 4c4d 000a 0000029 [root@www logs]# head -n 2 /home2/cache2/2/9c/439320ddec62f770fbc2eaca73c659c2 | tail -n 1 KEY: http://www.ads119.com/player/nanrenbang/nanrenbang-38212-93019-1234567890-4.html [root@www logs]# head -n 1 /home2/cache2/2/9c/439320ddec62f770fbc2eaca73c659c2 | hexdump 0000000 8813 4ebb 0000 0000 3fca 4eba 0000 0000 0000010 5de3 4ebb 0000 0000 b25d 7044 0000 007f 0000020 015b 5820 5448 4c4d 000a 0000029 [root@www logs]# cat /etc/redhat-release CentOS release 5.7 (Final) |
|||
| #53 | fixed | Nginx fails to accept new connection if active worker crashes | ||
| Description |
If nginx is configured with multiple workers, killing the active worker causes nginx to "hang". Further investigations(with nginx at debug level) showed that all threads are fine but none of the workers are getting the ngx_accept_mutex_lock. Master tries to release the ngx_accept_mutex_lock if the dead process was holding it [ https://svn.nginx.org/nginx/browser/nginx/trunk/src/os/unix/ngx_process.c?annotate=blame#L503] but doesnt look like the value is set anywhere. I think https://svn.nginx.org/nginx/changeset/612/nginx broke it. I have been using nginx only for a couple of months now so I am not very sure of the diagnosis, please feel free to correct. |
|||
