Hey Amos,
Today in many environments there is a very wide usage of ON-LINE
"libraries" since...
the server or a cache node is just "2 meters" from the developer.
(Picture the nearby Internet BOX being pointed as "This is the
Internet")
For me a 1MB file is still seems like too much for an Android APP in
many case but
the world is changing and a kernel of more then 1MB is embedded in
everyday devices around the globe.
I used to have huge disks for 80MB but today the in the same disk size
you can store TB's of data(20+++).
I am sure that it's a global issue but the demand for traffic and
on-line content is rising.
Just 10 years ago I had to have a huge wall filled with books to do
little research but today I have a local DB
which contains literally rooms filled with books and is searchable.
I believe that the admin should understand a bit http\https to allow all
these.
The next step is Google ROOT CA but... SSL-BUMP bumped everybody so not
only Google and FaceBook have their own ROOT CA.
This thread proves that there are out-there admins that think and ask
which makes me be happy.
It means that stupidity has not spread to some places like this list.
Eliezer
On 2018-06-27 22:56, Amos Jeffries wrote:
On 28/06/18 07:06, Verwaiser wrote:
Hello,
what would be the right way to implement the authentification bypass
list
linked from adobe:
https://helpx.adobe.com/content/dam/help/attachments/Creative_Cloud_for_enterprise_Service_Endpoints.pdf
Ouch. Rather a lot of domain names and explicitly states that it is
incomplete.
Some of them are *extremely* popular (eg Twitter, Google Maps, Google
Play Store). WTF why does ACC need Google Maps access?
Maybe looking for a User-Agent header string matching the tools that
break will narrow it down to not allowing just anyone access to all
those services.
I can write the list into a file, ok, but how can I setup the acl for
correct bypassig all the adresses from this list?
Is the "allways_direct" acl right?
No. 'always_direct allow' means "dont use any cache_peer for this
request".
There is no "bypass" directive. Every directive that you have
configured
a need for auth to happen needs adjusting such that it also works
without that auth requirement when your new ACL(s) match the
transaction.
Should I place it before the LDAP
authentication part in squid.conf?
Yes. For every directive which currently requires an auth related test,
place a test which matches the 'bypass' ACL first, OR make it so that
you don't have to require the auth details at that point.
NP: The latest Squid versions note ACL type which can be useful here
to
test username (the note named 'user' contains the username) without
requiring that it exists nor triggering auth.
The 'best practice' design is to configure http_access with an ordered
structure like so:
# The default / recommended security checks at the top
# ending at that default line "INSERT YOUR CUSTOM RULES BELOW HERE."
# custom allow/deny rules that do not need auth
# authenticate
http_access deny !login
# custom allow/deny rules that need auth credentials
# and finally ...
http_access deny all
The rest of your settings can assume that auth has taken place already
(*if* necessary) and not re-test it themselves.
Is there more to work on?
Everything which uses an authentication, username, or group ACL test
needs looking at to see whether a bypass is needed.
Amos
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
--
----
Eliezer Croitoru
Linux System Administrator
Mobile: +972-5-28704261
Email: eliezer@xxxxxxxxxxxx
_______________________________________________
squid-users mailing list
squid-users@xxxxxxxxxxxxxxxxxxxxx
http://lists.squid-cache.org/listinfo/squid-users
