[squid-users] Squid + oracle

[Amos Jeffries]

On 19/08/2015 12:15 a.m., Eliezer Croitoru wrote:
> Hey,
> 
> Currently I do not know of such a helper but it is possible to write one.

You surprise me Eliezer. Thought you had been around long enough to be
aware of these SQL database helpers:

<http://www.squid-cache.org/Versions/v3/3.5/manuals/basic_db_auth.html> and
<http://www.squid-cache.org/Versions/v3/3.5/manuals/ext_sql_session_acl.html>

(and for completeness)
<http://www.squid-cache.org/Versions/v3/3.5/manuals/log_db_daemon.html>

Any database that the Perl DBI module can connect to can be used as a
backend to these helpers.


> 
> On 18/08/2015 14:58, adricustodio wrote:
>> Hello guys.
>> I got a few questions.
>> I need to authenticate my squid on my oracle database, is that possible ?

Assuming you mean an actual SQL database such as Oracles' MySQL product
then the answer is yes.

Some other types of database such as BerkleyDB, ActiveDirectory,
eDirectory, RADIUS, or some flat file formats are also supported in
various ways.

Then there is always the possibility of writing your own helper like
Eliezer mentioned. Thats why we call them add-on helpers.


>> if its possible, i can do like a captive portal ? like a hotspot for
>> that ?

No.

The problem is simple: Would you hand your credit card and pin number to
any stranger that walked up and asked you for them ?
Similarly browsers refuse to hand over authentication credentials to any
MITM proxy that suddenly appears and demands credentials.


Like Eliezer mentioned, captive portals must use only _authorization_.

You redirect non-authorized traffic to a "login" page and have a DB
record created for clients that successfully completion of some task
there such as filing out a "login" form. Be aware that has nothing to do
with HTTP authentication though.

Squid comes with two helpers designed for captive portals :

* ext_sql_session_acl uses a SQL database to check some detail like
client IP, MAC address, or some combo with user-agent against records
stored there (ie by your portals "login" form).

* ext_session_acl in "ACTIVE" mode uses clicking on a link to access a
particular activation URL to create its database records. But that
helper maintains its own built-in database.


IMPORTANT: Be careful that the traffic you redirect to your captive
portal page is an HTML GET request by a browser; not a background tool
update, PUT / POST / CONNECT method, browser images/video fetches, etc.


>> The last question is... can i drop the connection of a user on squid
>> after X
>> minutes ?

No. That is not possible. A) there is no "user", B) only idle
connections can be closed arbitrarily, and C) HTTP is message-based not
connection-based.

(C) means that its entirely reasonable for a client to be redirected to
your portal login page for one request. Then make another request on the
same connection after portal login has succeeded. The second request
should be accepted.


>> For example, every 5 minutes connected the user need to authenticate
>> again ?

That is completely unrelated to TCP connections being open or closed.

In captive potal scenarios it is a session timeout. How you configure it
depends on the session helper being used. But make sure the
external_acl_type ttl= parameter is small enough for the timeout to
happen properly, since the timeout can ony reach the helepr on a
multiple of the ttl=N seconds.

With ext_sql_session_acl helper the DB records are maintained separately
in any way you like. You can set a job going that removed DB records
after a timeout. Or have the helper SQL query check a session creation
timestamp in the record is no more than X.

With ext_session_acl you set a timeout (-T) value and sessions are
closed at that time since being opened. You can also set an idle timout.

With a self-written custom helper you do it however you like.

Amos