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
