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 _______________________________________________ squid-users mailing list squid-users@xxxxxxxxxxxxxxxxxxxxx http://lists.squid-cache.org/listinfo/squid-users
