Geoff Cox wrote:

Hello Geoff,

I wonder if there is a way when using .htaccess /.htpasswd to restrict
access to a web site folder for a limited time, eg 0.5 hr?

not directly but if you can start programs automatically (cron or
something similar) you could modify the entries in the .htpasswd file
after 30 minutes, thereby forcing a reauthentication.

In comp.security.unix Geoff Cox <geoffacox@dontspamblueyonder.co.ukwrote:
Mon, 02 Feb 2004 11:50:28 -0100, Klaus Johannes Rusch
<KlausRusch@atmedia.netwrote:

>>Geoff Cox wrote:
>>
>>Hello Geoff,
>>
I wonder if there is a way when using .htaccess /.htpasswd to restrict
access to a web site folder for a limited time, eg 0.5 hr?
>>
>>not directly but if you can start programs automatically (cron or
>>something similar) you could modify the entries in the .htpasswd file
>>after 30 minutes, thereby forcing a reauthentication.

Claus,

The user would not be able to start the cron would they? Needs admin
permissions presumably?

Permissions to use 'cron' or 'at' ( which might be more appropiate
in this case ) is configurable and should not be a showstopper in
this case.

I am really looking for a labour saving device! The user would access
the folder using a "demo" id and password which would be valid for 0.5
hour and then the user id and password would be changed (random
process for new values?) so that oops! it has just accurred to me
that this approach would allow the user to have multiple sessions. I
guess this is where you are back to cookies which I did not wish to
use?

'at' is your friend :

at 30minutes < EF
chmod 000 <webfolder>
EF

Cheers

Geoff

In article <@4ax.com>,
Geoff Cox <geoffacox@dontspamblueyonder.co.ukwrote:

Mon, 2 Feb 2004 18:39:40 +0000 (UTC), phn@icke-reklam.ipsec.nu
wrote:
>
>'at' is your friend :
>
>at 30minutes < EF
>chmod 000 <webfolder>
>EF

but does this mean that the folder is no longer available to any user?
I need users who have subscribed to be able to use the files in the
folder whilst a user who wishes to get a real idea of what is on
offer, has access for only 0.5 hour is this possible?

I'd create a totally separate directory with only what you want to have
time-sensative access to. That means a separate .htaccess file with
it's own password file. The at job would run htpasswd to reset the
password to some random value or remove the user entirely from the
password file.

Mon, 02 Feb 2004 19:40:51 GMT
Geoff Cox <geoffacox@dontspamblueyonder.co.ukwrote:

Mon, 2 Feb 2004 18:39:40 +0000 (UTC), phn@icke-reklam.ipsec.nu
wrote:
>
>'at' is your friend :
>
>at 30minutes < EF
>chmod 000 <webfolder>
>EF
>
thanks for reply

but does this mean that the folder is no longer available to any user?
I need users who have subscribed to be able to use the files in the
folder whilst a user who wishes to get a real idea of what is on
offer, has access for only 0.5 hour is this possible?

You can assign user-level access privileges with
Solaris' ACL feature. For example,

# setfacl -m mask:r-x subscription
# setfacl -m user:sae:r-x subscription

The first command assigns a mask that allows read and
search access rights, and the second command gives the
user "sae" (and only that user) read and search rights
to the directory "subscription":

# ls -ld subscription/
drwx+ 2 root root 512 Feb 2 22:01 subscription/
# getfacl subscription

# file: subscription/
# owner: root
# group: root
user::rwx
user:sae:r-x #effective:r-x
group:: #effective:
mask:r-x
other:

Notice the #effective rights mentioned for user sae, they
are the union of the user's rights and the mask. To alter
all access rights, it suffices to change the mask.
After the required time has elapsed, simply remove the user's
access rights:

# setfacl -m user:sae: subscription
# getfacl subscription/

# file: subscription/
# owner: root
# group: root
user::rwx
user:sae: #effective:
group:: #effective:
mask:r-x
other:

More details on the setfacl (1) man page.

Take care,

In article <@4ax.com>,
Geoff Cox <geoffacox@dontspamblueyonder.co.ukwrote:

Mon, 02 Feb 2004 12:28:34 -0800, "Michael Vilain
<vilain@spamcop.net>" wrote:
>
>
>I'd create a totally separate directory with only what you want to have
>time-sensative access to. That means a separate .htaccess file with
>it's own password file. The at job would run htpasswd to reset the
>password to some random value or remove the user entirely from the
>password file.
>
this sounds useful - are you able to give me or point me at any
details on how to implement this?!

I'm assuming that access to this directory will be through Apache since
you mentioned .htaccess in the original post. I've seen similar
processes on other web sites that allow access to download a file that
'expires' after 30 minutes.

Here's what I think they do:

1) user fills in information into web form and clicks "Submit" button
2) CGI script creates temporary directory which is accessible to
web server (e.g. a Alias directive is in httpd.conf for it)
3) script copies files (including .htaccess) into temporary directory
4) script runs htpasswd to create user and password file referenced by
.htaccess file
4) script creates "at" job which will use htpasswd to change
password for user after 30 minutes
5) daily cron entry cleans up directories and password files (they
can have the same name if need be to make it easier) that are
older than N days (1, 7, 30, whatever).

That should get you started or whomever you hire to write this bit of
code. There may be permissions issues because the above script will run
as the web server, so it will need to be able to create directories and
run "at" jobs. The nightly cron can run as root or the web server. I'd
also add a logging feature to record when this was done, when it
expired, and when it was deleted.

It seems easier to me to create a separate directory for each request.
Unless you have a high-volume site, with nightly cleanup, you won't have
that much overhead and can track with ls what's still out there.

In article <vilain-4CCE51.11474903022004@comcast.ash.giganews.com>,
"Michael Vilain wrote:

>1) user fills in information into web form and clicks "Submit" button
>2) CGI script creates temporary directory which is accessible to
web server (e.g. a Alias directive is in httpd.conf for it)
>3) script copies files (including .htaccess) into temporary directory
>4) script runs htpasswd to create user and password file referenced by
.htaccess file
>4) script creates "at" job which will use htpasswd to change
password for user after 30 minutes

Why not have the CGI directly show and refuse to show the content -
thereby avoiding all the external commands ?

In article <slrnc207fe.44m.elvis@notatla.org.uk>,
elvis@notatla.org.uk (all mail refused) wrote:

In article <vilain-4CCE51.11474903022004@comcast.ash.giganews.com>,
"Michael Vilain wrote:
>
>1) user fills in information into web form and clicks "Submit" button
>2) CGI script creates temporary directory which is accessible to
web server (e.g. a Alias directive is in httpd.conf for it)
>3) script copies files (including .htaccess) into temporary directory
>4) script runs htpasswd to create user and password file referenced by
.htaccess file
>4) script creates "at" job which will use htpasswd to change
password for user after 30 minutes

Why not have the CGI directly show and refuse to show the content -
thereby avoiding all the external commands ?

That would work also.

You could track who had access by using a session cookie that records
the session key on the browser and IP address along with a date/time
stamp in a transaction file. The browser returns the cookie, you lookup
the value in a TIE'd variable (assuming perl) or MySQL table, and check
the date/time stamp. If it's 30 minutes, bail. , send the
file to the browser.

It's actually cleaner because there aren't any externals and it's all
controlled by the script and a transaction file or database.