Hello,
I enabled the cache manager and gave it a password as per the wiki.
However when I try and log in to the cache manager it gives me:
Access to the requested page has been denied
URL: cache_object://192.168.2.1/
I’m on Core 155 test build
I don’t get your error message but some other messages.
I have tried the following on both CU154 and 155 Test Build.
I enabled the cache manager and entered a password and then pressed the “Save and Restart” button at the bottom of the page. This is important as the save updates the squid.conf file and the restart gets squid to take notice of the updated conf.
I then get the Cache Manager Interface screen
I leave the Manager name blank and enter the password I put in the Cache management section and press continue. I then get
Now if I press any of these menu items I get an error message. Here I pressed the HTTP Header Statistics and got
If I remove the password from the cache management section and press the Save and Restart button and then get the same Cache Manager Interface screen but this time I leave the password empty and press continue.
I then get
Now the menu items available are in blue (these don’t require and password) and the ones requiring a password are in black and have (hidden) at the end of their line. Now I press the same HTTP Header Statistics button and now get
So I can get the cache manager working without a password on the menu items that don’t need a password but if I set a password then all of the menu items give me the same error message.
Based on the Squid website I tried adding various acl’s and http_access statements to include.acl. These are added into squid.conf when Save and Restart is pressed. However, all my attempts just resulted in me getting an error message in place of the Cache Manager Interface, so my attempts were making me go backwards. I have come to the conclusion that I definitely don’t know enough about this to fix it but I can live with the menu items available without a password.
It could also be that there is a bug in the cache management section with password but it would be good to hear if someone has been able to access the cache manager menu with a password and successfully opened any menu items.
Let’s check for differences we have in the rest of the Web Proxy page setup then.
I have Enabled on Green checked and Transparent on Green not checked.
I have 800 on the Proxy port. From your Cache Manager Interface it looks like you have that set to 808. Not sure that would make a difference.
I do not have URL filter or Update accelerator enabled.
Upstream Proxy is all blank.
I am presuming that 192.168.2.0/24 is your Green Network. I was also using the Green Network.
Cache Management entries are all default.
Destination ports is all default.
The Network Based Access Control section is default and has both the Green and Blue subnets listed.
I have just realised that in Destination ports there is a line for port 800 but not for port 808. Not sure if that could be a factor but maybe try your configuration with the port set to 800 to see if it then works. If yes then you might need to add a line to the Destination ports for 808. If no then we are still lokking for some other difference.
I have enabled on GREEN and BLUE checked, Transparent on both not checked. Yep using port 808.
I have URLFilter enabled but not Update accelerator.
Upstream proxy also all blank.
Yup that is correct that’s my green network.
I do have 808 allowed as a destination port for Squid.
However I am on BLUE 192.168.3.0/24 and I realise it is trying to access GREEN which may be an issue.
Without a firewall rule to allow it, yes that would probably block it.
Hopefully when you solve that it will work for you. 
actually, looking at that message again I knew it seemed familiar and that is the page you see when a http URL is filtered.
So it is the URLFilter that is blocking access to cache manager and I have no idea why it is doing that.
When I turned off URLFilter I can access it.
Now I have the same problem that you do, it tells me I am not authenticted when trying to access password areas. Same error as you.
Aah.
I was hoping it would work for you so I could see from your setup what I had missed.
I will have a look into the page source code and see if that gives any clues.
Hopefully someone has got it working now or in the past and can let us know.
At least without the password you can access around 80% of the menu items.
I will come back to this thread if I find anything further.
It looks to me that the auth isn’t being passed on when accessing any further pages after logging on to that page
Also I checked my pac file and definitely local subnets are “DIRECT” and should not be going through Squid so I am baffled as to why URLFilter is filtering them.
I had a look through the WUI source code. The stage we get to with the Cache Management Interface is part of cachemgr.cgi which comes with the squid package. That is stored as a binary in IPFire.
I went back to thge squid tarball and found the code that creates it. Unmfortunately it is in c which I struggle to be able to understand sufficiently.
However I was able to find out that cachemgr.cgi is finding the password in squid.conf because otherwise the code makes the menu url no longer be a link and places (hidden) at the end of it. So with the password we get the full url links for each menu item and no (hidden) at the end of any of them. So the auth is passed on as far as creating the menu url’s. The problem must be occurring after that but I can’t find the menu url’s in the cachemgr.cc code so it probably is in another one of the programs in the tarball but I can’t figure out which.
I think we wait for a while to see if anyone flags up that they do have it working and if we get no response from anyone then I will raise it as a bug in the IPFire bugzilla.
1 Like
Yep that’s what I think too, something along the lines of the authorization bearer isn’t being passed along for the subsequent pages only the main menu.
If that is correct then the problem is in the squid part so I will also have a look in their bug system to see if anyone has flagged a problem there or not.
3 Likes
I checked in the squid bugzilla.
There were two entries related specifically to the cachemgr.cgi file from 2014 and 2016. Neither of them were anything to do with authentication.
There was one related to the cache manager having an error in parsing of an external url so not related to the menu url’s or authentication.
I also went through the squid users mailing list archives to the start of 2019 searching for anything related to cache manager. There was one set of entries but it was related to the error in parsing of an external url.
With no comments of any sort I am believing less now that the problem is with squid.
I then installed CU150 into my testbed VM with just red and green and no changes to anything after install except enabling web proxy on Green, enabling logging and enabling cache manager with a password.
Exactly the same problem as described earlier in this thread with cache manager access denied due to a problem in authentication. This was with squid 4.13 compared to 4.14 in CU154 and 155.
I then installed CU142. Exactly the same problem. This time squid is version 4.10.
So EITHER the problem has been there since CU 142 and squid 4.10 and is still there in CU155 and squid 4.14
OR more likely we are doing something wrong somewhere in setting the authentication up either with acl’s in include.acl or somewhere else.
I will ask on the IPFire development mailing list about this problem to see if they can highlight something obvious before I go thinking about raising an IPFire bug.
1 Like
Duuuuh.
The one thing I didn’t do till now was go do a search in the IPFire bugzilla. I found that our exact conversation happened in mid 2020 in this forum and a bug was raised on it.
Basically other people identified that the Cache Manager only works with the password left blank.
Bugzilla link
https://bugzilla.ipfire.org/show_bug.cgi?id=12451
In the bug is a link to the forum thread. A conclusion reached there is
There is something jacked up in the squid proxy code that if you have a password in there, it will allow you to the cache manager menu but will choke on all of its URI paths.
1 Like
IPFire 2.29 (x86_64) - Core-Update 185 Development Build: master/0564584a after upgrades
Today I encountered a similar problem after clicking “Activate cachemanager:” and then “Continue” with an empty password
Curiosity:
After typing some string into the field “Visible hostname:”
and then clicking “Save and Restart” I was able to open the “Cache Manager menu”
Regards