Re: Enforce reloading of page when using the back-button

>> This was discussed before on this list. 

>I would appreicate a pointer to the relevant 
>part of the archive. 

Sorry Dan, couldn't find it. Maybe it was another
list. Couldn't find it in my mail archives either.
Will send it to the list if I find it.

Dan, you wrote,

>> I write full blown applications using http/html.  
>>The fact that I can't tell the browser not to 
>>cache the back button is a right pain and it 
>>would be perfectly appropriate for me to prevent 
>>this for my application. 
>
>I'm afraid that this claim, without supporting >justification, does not assure me of anything. 
>Would you please help me understand why it is you 
>feel that it is "perfectly appropriate"? 

I don't know if I can reassure. but I will try to 
explain. I have developed an application that 
publishes patient medical record information on
both intranet and internet. Obviously security is 
a prime concern, particularly within a hospital where
there is a high turnover of users on a minute to minute
basis using the terminals. We elected to go
with a web based solution 3 years ago. I have spent
much of the last few years investigating the security
issues. In addition currency is of great importance
too, since doctors want to see pathology results the
minute they are available

I use all the known headers to prevent caching. And additionally I add a random value to every URL
to check that no caching is going on. I feel that 
this is appropriate in these circumstances.

I impose sessional logins on the user. They must 
authenticate occasionally or get logged out. This
is a base requirement of my application.

But once logged out, there is nothing to stop anyone
walking up to the computer and pushing the back button
and seeing whatever the last user saw. They can't get
new information. My information isn't in the cache, but
in the history.

I realise that I am pushing the envelope for what web
applications can do. But it's frustrating to overcome 
all the other obstacles and not this little one.

And Arjun wrote,

>A browser is a user-agent, with more or less 
>known capabilities (i.e. what it can and often 
>does on behalf of the user.).  If your "full 
>blown" application is not cognizant of basic browser >functionality, then the fault is not the browser's. 

I'm perfectly aware of what a browser can do. But I
believe that the [current] http specification is 
self-limiting in this regard. And I don't think it's
unreasonable to look for a work-around. 

><clue>The browser is *mine* to use, 
>not *yours* to command.</clue> 

I don't think it's so simple, else there would be no
commands relating to caching at all. It's a 2 way 
street. The browser represents the user, the server 
represents the owner of the data stored on the server.
For my data in this application, the data is the 
*servers* and the *user* accesses it at the data owners
discretion. 

It's highly unsociable to prevent caching of static 
public content - and why would you want to? But secure dynamic content? How can you allow caching?

The HTTP standard has historically assumed that once
the user[-agent] has the data they are permitted to 
do whatever they wanted. I am pushing the envelope to
publish data where this is not the case. The user is
allowed to use it how they want but the user-agent 
isn't, since it is shared between users on a 
[potentially] non-secure system

Grahame

Received on Wednesday, 8 March 2000 17:45:30 UTC