Re: [squid-users] block domains based on LDAP group and force re-authentication every 30 minutes

On 2014-02-21 03:39, Wim Ramakers wrote:
> I now have implemented FredB’s idea into my own basic helper in php,
> which says ERR when the credential expire date time is in the past.
> That seems to work also for iPads :)
> That expire date time can be set (to now + xx min) via a php page and
> correct credentials.
>
> Working fine, except for the fact that I now want to present the user
> the page to activate his credentials every 30min…
>
> My target workflow is that when a user tries to access a page he is
> not allowed to he will FIRST get the credential expire time update
> page where he can activate a ticket for a specified time THEN when he
> tries again he must get the basic auth popup where his credentials
> will work now. The user may not first get the auth popup and need to
> know by himself he has to go to the credential expire time update page
> first. I’ve tried some deny and allow rules with my acl's, but can’t
> find the good combination. If I could have the user redirect
> automatically to the credential expire time update page every xx
> minutes, that would solve my problem.

For that you check the session helper before the auth helper.

   acl loginCheck proxy_auth REQUIRED
   acl sessionPage external ....
   deny_info ... sessionPage

   # check if session has expired and show that page
   http_access deny !sessionPage

   # check if provided credentials are still valid
   http_access deny !loginCheck

NP: session page should even be able to be passed the old
Proxy-Authentication header to see the old credentials as they expire.

>
> Another question: the debian package of squid I use is v3.1.20, which
> has the old session helper and only has only -t (timeout time) and not
> -T (always after time) parameter. Is it possible to just add the new
> helper to my squid version (can i download it from somewhere?)?

Yes. The helper and Squid are separate programs. Except in a few cases
where we are updating the communication between them in lock-step they
are completely independent.

If the updated helper is one which is provided with Squid you can
download and build the latest squid code then copy the built helper
binary into your system libexec directory with the older ones.

Note that the mention of LOGIN/LOGOUT in the -T option description is
referring to the session "LOGIN" URL being fetched. It has nothing to do
with HTTP login popups by the browser.

You may be better off using the SQL-session helper from squid-3.4. It
does not manage login/logout states itself, but relies on the session
page being scripted to update an SQL database for whether the
credentials it is checking are valid. You can use the basic_db_auth
helper to check the same SQL database for HTTP login (and the popups).

It is a perl script, so:
  * select "download file" at
http://bazaar.launchpad.net/~squid/squid/3.4/view/head:/helpers/external_acl/SQL_session/ext_sql_session_acl.pl.in
  * save without the ".in" suffix, and
  * change @PERL@ at the top of the script to your systems bin/perl path.
  * assign execution permissions (chmod +x) to the script
  * update your squid.conf and reconfigure Squid

>
> Or should I just make my own external helper for the sessions? in the
> basic auth helper i get the username and password, but what do i get
> with the external helpers? just the name? When do I return which
> value?

That depends on your squid version. Squid-3.4 adds annotation support,
so you can get anything you like out of the helpers. With Squid-3.1 you
get only username out of auth helpers and a few limited tag=, log=,
message=, user=, password= out of the external ACL ones.

Note the external_ACL user= and password= results are not authentication
credentials. They are authorization labels instead.

Amos
Received on Thu Feb 20 2014 - 21:05:43 MST