Brandon, I'm not at all suggesting that we should change Firefox's default setting (which normally caches secure pages in memory) so as to make it cache the same on disk. Setting browser.cache.disk_cache_ssl  to true  was to confirm what Cathal said-that Firefox caches pages in memory by default and changing that to a disk cache meant that DNN was able to take advantage of that change with Authenticated Cacheability set to ServerAndNoCache doing what it was meant to do (invalidate the cache on a logout). However, this is not a solution to the problem. A viable and sustainable solution, IMHO, would be one that would enable DNN to invalidate cached secure pages stored even in memory, and the examples I'd given of other websites doing exactly that, but not DNN led me to believe that the invalidation strategy adopted by DNN is perhaps flawed and therefore needs to be reviewed. However, I'm still waiting for someone who can tell me where to set these as they may prove to be the solution(s) to this problem :-

response.Cache.SetExpires(DateTime.UtcNow.AddMinutes(-1))

response.Cache.SetCacheability(HttpCacheability.NoCache)

response.Cache.SetNoStore()

Thank you, Mitch for taking the time to respond.

As far as possible, we should mitigate the issue through code or settings.
In default.aspx.vb, under If Request.IsAuthenticated = True and before the last End IF added the lines :

response.Cache.SetExpires(DateTime.UtcNow.AddMinutes(-1))
response.Cache.SetNoStore()

and now it works, thanks to Cathal. Issue resolved in Firefox!

Mark,

AFAIR the display user profile option is simply a way of ensuring that the details a user registered with can't get altered after registration. However, their username/password will always be editable (they're an intrinsic part of the user, not extended properties such as the profile). What you're talking about is "security by obscurity" rather than a security violation. Fixing that quirk would not stop the user having the ability to change their password - the user can simply provide the correct url which will validate that they have the rights to see their user details and display correctly. I would recommend that you do not share 1 dotnetnuke user across multiple actual users, that is not a very safe setup. If you need to grant access to a shared page, create a role (e.g "seasonal employee") and add users to that role.

Cathal