The API change was documented in <http://www.squid-cache.org/Versions/v3/3.2/RELEASENOTES.html#ss2.13> It does not explicitly call out the authentication side effects or provide a config example though. The expectation was that most people use tools to access the reports and the config changes would be documented with the tools as they changed. (The https:// access still has a few bugs to work out related domain aliases and cert CommonName's.) Amos On 25/01/18 14:59, Yuri wrote: > Amos, this is good news. > > Is this clear documented anywhere to write good article in wiki about it? > > > 25.01.2018 07:55, Amos Jeffries пишет: >> On 25/01/18 14:25, Yuri wrote: >>> Everything is a little worse. If you need a password to access the >>> cachemanager - it will shown in the logs. >> "worse" implies it was better some time beforehand. >> >> The old manager API is the one which places password in clear-text in >> the URLs. It may not have told you that was what it was doing, but still >> the security was really crap. >> >> If you are using the current API with http(s):// URLs they do not >> contain any credentials in the URL and you can configure authentication >> more secure than Basic to be used by using http_access permissions >> instead of the cachemgr_passwd mechanism. >> >> >>> I believe that this is a bug >>> and a hole in security. >>> >> Using the old insecure manager API is a hole yes. But not a new one. >> >> >>> Preventing by ACL can be workaround, but hardly this is feature. >>> >> This is backward compatibility feature for people still using tools that >> require the old API. Making a crappy insecure API "secure" requires work. >> >> Amos >> _______________________________________________ >> squid-users mailing list >> squid-users@xxxxxxxxxxxxxxxxxxxxx >> http://lists.squid-cache.org/listinfo/squid-users > _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
