|
|
Jun
19
Posted by:
cathal connolly
6/19/2006 4:00 AM
Webpage contents can be cached in a number of different places including the browser making the request, the Web server responding to the request, and any cache-capable devices, such as proxy servers, that are in the request or response stream. In asp.net the HttpCacheability Enumeration has a number of different settings with ServerAndNoCache being the one that was hardcoded into DotNetNuke. This setting ensured that content was cached at the server but all other machines are explicitly denied the ability to cache the response. Whilst on first look this looks very inefficent, as repeat page requests have to pull down fresh copies of repeated files, it's actually a security best practice. It ensures that if you log out, no-one can access your previous pages by pressing the back button, or viewing the temporary internet files.
However, this has the twin drawbacks of causing the "Warning: Page has Expired" warning to be shown when the back button is used, as well as impacting performance. Whilst the default setting is the best setting for sites with secure content, in many cases it can be overkill and can be safely reduced. With 3.3/4.3, this setting has now been exposed as a host level setting that can be altered by logging in as a superuser and going to Host->Host Setting, expanding out Advanced Settings->Other Settings and changing the Authenticated Cacheability value. Many sites would benefit from a better user experience and performance boost by changing to another value such as Public.
8 comment(s) so far...
Re: Webpage Cacheability
So should we trade security for better user experience? What's your opinion on this?
By elevocm on
6/20/2006 1:46 AM
|
Re: Webpage Cacheability
No, you should never sacrifice security for a better user experience, but in some cases your site does not require as restrictive a security setting. Theres no definitive answer - individual sites will have to assess and decide if it suits them e.g. on my personal site I'll use Public as I'm the only authenticated user. For many popular sites Public will also suit, but if your site offers anything for sale, it's not a wise choice IMHO.
By cathal on
6/20/2006 10:27 AM
|
Re: Webpage Cacheability
Yes absolutely, but shouldn't this be at site level as well!
By doop on
6/20/2006 11:49 AM
|
Re: Webpage Cacheability
Having it at the site level is a tough call. Because all sites share a common database and application code, it is possible that a portal with weaker security could compromise another portal in the same host with stronger security. Because this enhancement was done at the very end of the release cycle we didn't want to open it up too much without doing a much more thorough review of the implications, we decided to leave this setting at the host level.
By jbrinkman on
6/20/2006 11:56 AM
|
Re: Webpage Cacheability
Much better to have it at the host level than nowhere :-)
By microworks on
6/20/2006 1:36 PM
|
Re: Webpage Cacheability
Having it at the host level also means that you need to make sure that you are not compromising any sub-portals in the system, so keep that in mind if you have sub-portals.
It really should be a page level setting that gets it's default from the site settings if not specified, and the default of the site settings should be the most secure as a default.
By snapsis on
6/23/2006 3:43 PM
|
Re: Webpage Cacheability
Cathal, just to understand; when you say it is a security risk, do you mean that other users could see your content if it was cached from THEIR browser, or it is only a risk if you share a PC with someone who could access the History of YOUR browser? If it increases performance I would like to try it on Smart-Thinker, but a user should never be able to see another user's cached version of the page.
Thanks
By rodneyjoyce on
8/20/2006 5:39 PM
|
Re: Webpage Cacheability
It's more a best practice than a risk. It stops people who have physical access to your machine from accessing non-expired content on it i.e. the contents of the temporary internet files folder.
By cathal on
8/20/2006 5:42 PM
|
|
|