Bug 12451 - IPFire Core 145 Cache Management Password Setting Causes Failure to Authenticate
Summary: IPFire Core 145 Cache Management Password Setting Causes Failure to Authenticate
Status: NEW
Alias: None
Product: IPFire
Classification: Unclassified
Component: squid (show other bugs)
Version: 2
Hardware: unspecified Unspecified
: - Unknown - Minor Usability
Assignee: Assigned to nobody - feel free to grab it and work on it
QA Contact:
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2020-06-28 21:23 UTC by Eric Spillman
Modified: 2021-03-22 15:11 UTC (History)
3 users (show)

See Also:


Attachments
menu screen with password defined (49.40 KB, image/png)
2021-03-21 14:18 UTC, Adolf Belka
Details
error message after selecting menu item (25.87 KB, image/png)
2021-03-21 14:23 UTC, Adolf Belka
Details
menu screen with blank password (63.52 KB, image/png)
2021-03-21 14:24 UTC, Adolf Belka
Details
result from selecting a menu item with no password set (26.31 KB, image/png)
2021-03-21 14:26 UTC, Adolf Belka
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Eric Spillman 2020-06-28 21:23:04 UTC
Please see below for notes in troubleshooting.  When you add a password to the GUI field, and it make the entry in squid.conf, it allows inital login to the Management GUI for cache, however any subsequent URI's get an authentication error.  

Pictures are available for review in the below thread.

https://community.ipfire.org/t/cache-manager-menu-for-web-proxy-not-loading/2021/78?u=mustangint1


thx
Comment 1 Adolf Belka 2021-03-21 14:16:54 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.
Comment 2 Adolf Belka 2021-03-21 14:18:52 UTC
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
Comment 3 Adolf Belka 2021-03-21 14:23:42 UTC
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.
Comment 4 Adolf Belka 2021-03-21 14:24:38 UTC
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
Comment 5 Adolf Belka 2021-03-21 14:26:41 UTC
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
Comment 6 Michael Tremer 2021-03-22 13:49:15 UTC
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.
Comment 7 Adolf Belka 2021-03-22 14:43:40 UTC
(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.
Comment 8 Michael Tremer 2021-03-22 14:47:09 UTC
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
Comment 9 Adolf Belka 2021-03-22 15:11:36 UTC
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.