At 10:36 PM 05-02-2002 +0100, Patrik Birgersson wrote:
>
>2. The "content" script checks $ENV{'HTTP_REFERER'} to verify that the
>user came from the login script, checks the cookie (both for presence and
>content), as well as setting http header with 'no-cache' and html header
>'http-equiv expires date_way_back'.

REFERER is useful to help protect clients from CSS attacks, but not very
useful for protecting the server from the client.

The way I'm doing login is:

login form - display login form
login authentication - authenticate and HTTP-redirect to next page
content page - display the stuff plus welcome.

The HTTP-redirect after login authentication stage stops people from
clicking back to just after the login form and reloading to repost the
username and password.

>However, if a user log in and then goes to another page (either by typing
>address or using bookmark) and then uses the back button he/she will get
>back in. (not good).

Shouldn't the nocache and other cache headers tell the browser not to cache
it?

>I am able to "detect" that the user leaves the login area and then
>destroy the cookie, which leads to that if the user is "backing in"
>he/she will be thrown out as soon as he/she "does" anything in the login
>area.

As far as I know you can't do this easily in a 100% manner and maybe you
really want to do something else. But if you really want to do it here's an
idea: have two frames, one showing the content, and one frame doing a very
slow and long download from a custom script, maybe displaying messages with
javascript (optional) to autoscroll. Once the download is interrupted, the
custom script notices and marks the user as logged out or having left that
section.

It does work mostly, but it's a kludge and sometimes some browsers just
stop the download for no apparent reason - even though I send one byte of
data every second :(.

>I would like to be able to prevent the user from even "backing in" to see
>the last page displayed. I know that one can't affect the browser's back
>button for security reasons and by browser specifications, but perhaps
>there is something that could be done??

The nocache and cache control stuff seems to work for me - even using http
and IE.

e.g. perl version:
        print
$q->header(-type=>'text/html',-expires=>'now',-Pragma=>'no-cache',-Cache_Con
trol=>'no-cache');

I don't understand your problem fully. Is the last page being displayed
because it's cached or is it because your application actually displays it?

If your application actually displays it, then it is not clear to me when
you want it to display the page and when you don't. Maybe you will need to
use sessions and session cookies and expire then after some time.

Regards,
Link.

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]