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 the
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 but
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.
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 tha
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
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 v
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:
>
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, must
[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:
$val){
session_unregister("$key");
}
// We destroys
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
because
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:
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 ou
12 matches
Mail list logo
