Let's look at the sample code in Listing 2.
Fuente: http://www.linuxjournal.com/content/flexible-access-control-squid-proxy…
Listing 2. The Proxy Redirector
1 #!/usr/bin/perl
2
3 use DBI;
4
5 $blocked = "http://192.168.1.10/blocked.html";
6
7 my $dbh = DBI->connect("dbi:mysql:authentication:host=
↪192.168.1.10", "user", "password") || die("Can\'t
↪connect to database.\n");
8
9 $|=1;
10
11 while (<STDIN>) {
12 my($sth, $r, $c);
13 my($url, $client, $d, $method, $proxy_ip, $proxy_port);
14
15 chomp($r = $_);
16
17 if ($r !~ m/\S+/) { next; }
18
19 ($url, $client, $d, $method, $proxy_ip, $proxy_port)
↪= split(/\s/, $r);
20
21 $client =~ s/\/-//;
22 $proxy_ip =~ s/myip=//;
23 $proxy_port =~ s/myport=//;
24
25 $sth = $dbh->prepare("select * from web_clients
↪where ip=\'$client\'");
26 $sth->execute();
27 $c = $sth->fetchrow_hashref();
28
29 if ($c->{blocked} eq "1") {
30 send_answer($blocked);
31 next;
32 }
33
34 if ($c->{whitelist_only} eq "1") {
35 if (!is_on_list("dom_whitelist", $url)) {
36 send_answer($blocked);
37 next;
38 }
39 }
40
41 if ($c->{filtered} eq "1") {
42 if ($c->{games} eq "0") {
43 # Check URL to see if it's
↪on our games list
44 }
45
46 if ($c->{flash} eq "0") {
47 # Check URL to see if it looks
↪like flash
48 }
49
50 send_answer($url);
51 next;
52 }
53
54 if ($c->{open} eq "1") {
55 send_answer($url);
56 next;
57 }
58
59 send_answer($url);
60 next;
61 }
62
63 exit 0;
64
65 #############################################################
66
67 sub send_answer {
68 my($a) = @_;
69 print "$a\n";
70 }
71
72 sub is_on_list {
73 my($list, $url) = @_;
74 my($o, @a, $i, @b, $b, $sth, $c);
75
76 $url =~ s/^https*:\/\///;
77 $url =~ s/^.+\@//;
78 $url =~ s/[:\/].*//;
79
80 @a = reverse(split(/\./, $url));
81
82 foreach $i (0 .. $#a) {
83 push(@b, $a[$i]);
84 $b = join(".", reverse(@b));
85
86 $sth = $dbh->prepare("select count(*) from
↪$list where name=\'$b\'");
87 $sth->execute();
88 ($c) = $sth->fetchrow_array();
89
90 if ($c > 0) { return $c; }
91 }
92
93 return $c+0;
94 }
95
The main loop begins on line 11, where it reads from STDIN. Lines
11–24 mostly are concerned with parsing the request from the Squid
proxy. Lines 25–28 are where the program queries the database to see
what the particular client's permissions are. Lines 29–57 check to see
what permissions were read in from the database and return
appropriately. In the case where the client is allowed "filtered" access
to the Internet, I have a skeleton of the logic that I have in mind. I
didn't want to bog this article down with trivial code. It was more
important to demonstrate the structure and general logic of a Squid
proxy redirector than it was to supply complete code. But you can see
that I could implement just about any conceivable access policy in just a
few lines of code and regular expressions.
The send_answer() function starting on line 67 really doesn't do much
at this point, but in the future, I could add some logging capability
here pretty easily.
The is_on_list() function starting on line 72 is perhaps a bit
interesting. This function takes the hostname that the client is trying
to access and breaks it up into a list of subdomains. Then it checks if
those subdomains are listed in the database, whose name was passed in as
a parameter. This way, I simply can put example.com in the database,
and it will match example.com, www.example.com or webmail.example.com, for example.
By passing in different table names, I can use the same matching
algorithm to match any number of different access control lists.
As you can see, the code really isn't very complex. But, by adding a
bit more complexity, I should be able to enforce just about any access
policy I can imagine. There is, however, one area that needs to be
improved. As written, the program accesses the database several times
for each access request that it handles. This is extremely
inefficient, and by the time you read this, I probably will have
implemented some sort of caching mechanism.
However, caching also will make the system less responsive either to
changes to access policy or access control lists, as I will have to wait
for the cached information to expire or restart the proxy dæmon.
In practice, I've seen something that is worth mentioning. Most Web
browsers have their own caching mechanism. Because of this cache, if you
change an access policy at the proxy, your clients aren't always aware
of the change. In the case where you "open up" access, customers will
need to refresh their cache in order to access previously blocked
content. In the case where you restrict access, that content still may
be available until the cache expires. One solution is to set the local
cache size to 0 and simply rely upon the proxy server's cache.
Also, once the clients have been configured to talk to a proxy on the
local network, it becomes possible to swap in different proxies or even
to daisy-chain proxies without the client needing to do anything. This
opens up the possibility of using Dan's Guardian, for example, to do
content filtering in addition to access control.
By this time, many of you might think I'm some kind of uber-strict
control freak. However, my family spends a lot of time on the
Internet—sometimes to a fault. Most of the time, my family members use
the Internet in an appropriate manner, but when they don't, my wife and I
need a means of enforcing household rules without having to keep a
constant watch over our kids.
Fuente: http://www.linuxjournal.com/content/flexible-access-control-squid-proxy…