Jean-Christian Imbeault wrote:
1- user logs in
2- user goes to restricted area
3- user views pages, orders an item, changes his account settings, etc ...
4- user logs out
5- user is sent to log out page
6- user hits back button ...
And here my problems start ... even though the user has logged
Tularis wrote:
I adives to make sure the browser doesn't cache it *at all*.
This can be done using (one, or more) of the following headers:
// HTTP 1.1 compliant:
header(Cache-Control: no-store, no-cache, must-revalidate);
header(Cache-Control: post-check=0, pre-check=0, false);
// HTTP 1.0
Jean-Christian Imbeault wrote:
I'll try this out and see what I get. Though I have read that not all
browsers follow cache-control directives ...
Exactly - and some don't follow other HTTP header directives to the
letter either. You will not be able to 'secure' this stuff 100% simply
[CUT]
I am using SESSION on al my secure projects
I use a file structur as this:
(loginform) - logincheck.php (if not ok-back2login | if ok (start an
session)(forward to the secure pages))
When the user logs out:
(securepages)-logout.php:
?PHP
//go through all the session array an unregister the
On Wednesday 01 January 2003 19:24, Jean-Christian Imbeault wrote:
Tularis wrote:
I adives to make sure the browser doesn't cache it *at all*.
This can be done using (one, or more) of the following headers:
// HTTP 1.1 compliant:
header(Cache-Control: no-store, no-cache,
On Thursday 02 January 2003 01:56, David Tandberg-Johansen wrote:
[CUT]
I am using SESSION on al my secure projects
I use a file structur as this:
(loginform) - logincheck.php (if not ok-back2login | if ok (start an
session)(forward to the secure pages))
When the user logs out:
Instead of doing a foreach to unset your session variables you can use
session_unset(); which will unset all your session variables for you.
Additionally if you are wanting to remove a cookie from a visitor's
browser you should use setcookie, not unset $_COOKIE, $_COOKIE allows
you to access the
I have tested this with all kind of browsers on WIndows, and to make a clean
cut I had to do so..
Jason Sheets [EMAIL PROTECTED] wrote in message
[EMAIL PROTECTED]">news:[EMAIL PROTECTED]...
Instead of doing a foreach to unset your session variables you can use
session_unset(); which will
You might consider using cookies that keep track of the user's
login name and a bitwise status to control AAA (Authentication,
Authorization, and Access0 controls instead of using session variables.
-mel
On Wed, 1 Jan 2003, Jean-Christian Imbeault wrote:
On my web site there are some areas
A lot has been said on the issue already, so I'll attempt to keep mine
brief.
Cache control will help a little, but not all browsers support it. Yes, it
will cause a little more traffic on your site, and yes it will help keep
some people from clicking back, but it certainly won't FIX anything.
Justin French wrote:
I know it sounds simple, but try to analyse what other big sites are doing
in this situation:
That's exactly what I did, but I don't understand *how* they do it hence
my question.
I surfed some of the big sites and saw that they do not break when a
user hits the back
Jason Wong wrote:
The cache-control directives are only supposed to be followed if the page was
to be _explicitly_ reloaded or refreshed. The BACK button (as specified in
the standards rfc something or another) is NOT supposed to reload or
refresh a page -- it is supposed to redisplay
12 matches
Mail list logo
