| Summary: | IPFire Core 145 Cache Management Password Setting Causes Failure to Authenticate | ||
|---|---|---|---|
| Product: | IPFire | Reporter: | Eric Spillman <crunchwizard01> |
| Component: | squid | Assignee: | Assigned to nobody - feel free to grab it and work on it <nobody> |
| Status: | NEW --- | QA Contact: | |
| Severity: | Minor Usability | ||
| Priority: | - Unknown - | CC: | adolf.belka, bbitsch, michael.tremer |
| Version: | 2 | ||
| Hardware: | unspecified | ||
| OS: | Unspecified | ||
| Attachments: |
menu screen with password defined
error message after selecting menu item menu screen with blank password result from selecting a menu item with no password set |
||
|
Description
Eric Spillman
2020-06-28 21:23:04 UTC
This bug has been re-discovered in Core Update 154. https://community.ipfire.org/t/cant-use-cache-manager/4936 Re-discovered that Cache Manager menu access works only if you don't use a password. Using a password gets you the menu list but every entry fails due to cache manager access denied due to an authentication problem. If password is left blank then all the menu items that don't require a passowrd now work and the ones that do require a password are unlinked so can not be accessed. Created attachment 866 [details]
menu screen with password defined
This shows the menu screen when the password has been defined in the Web Proxy WUI page
Created attachment 867 [details]
error message after selecting menu item
This is the error message obtained from every cache manager menu item if a password has been set.
Created attachment 868 [details]
menu screen with blank password
This is the menu screen when the password entry in the cache manager section of the web proxy WUI has been left blank
Created attachment 869 [details]
result from selecting a menu item with no password set
This shows that with a blank password then the menu items that are selectable do now provide a result as shown here with the HTTP Header Statistics
Can we verify that the browser is sending the password again? I do not think that we have recently touched anything that should break this. (In reply to Michael Tremer from comment #6) > Can we verify that the browser is sending the password again? > > I do not think that we have recently touched anything that should break this. How do I verify that? All my findings were based on using SeaMonkey (a Firefox fork). I have also now tested it with the latest version of Firefox and the same happens. Either using the debugging feature of the browser and check whether it is including the credentials in the HTTP request it is sending or using WireShark to sniff the packets on the network.
> https://developer.mozilla.org/en-US/docs/Tools/Network_Monitor/request_details
This is the uri from the menu item that I selected. https://iapetus.saturn.pimb.org:444/cgi-bin/cachemgr.cgi?host=192.168.26.254&port=800&user_name=&operation=http_headers&auth=MTkyLjE2OC4yNi4yNTR8MTYxNjQyNTMxNnx8 Here is the Header information from the debugger. GET /cgi-bin/cachemgr.cgi?host=192.168.26.254&port=800&user_name=&operation=http_headers&auth=MTkyLjE2OC4yNi4yNTR8MTYxNjQyNTMxNnx8 HTTP/1.1 Host: iapetus.saturn.pimb.org:444 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 SeaMonkey/2.53.5 Accept: text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8 Accept-Language: en-GB Accept-Encoding: gzip, deflate, br Referer: https://iapetus.saturn.pimb.org:444/ DNT: 1 Authorization: Basic YWRtaW46Sm1pMz80NHRCTXY4SCV2UGQma2A= Connection: keep-alive Upgrade-Insecure-Requests: 1 It gives the status code as 403 401 Unauthorized I think this was what you were requesting. If not then let me know and I will have another look. |