When a user accesses a site page without being authenticated, the portal presents the login page. However, when the Sakai instance is using http (not https), this page is cacheable by intermediate caches.

For example, the headers from:

wget --no-proxy --save-headers -O authpage-direct http://qa1-za.sakaiproject.org/portal/site/804f70fc-334d-4879-80c5-f10889008c53/page/81f280d2-f521-4589-0016-909ec3be4d78

are as follows:

Date: Wed, 28 Jun 2006 14:07:14 GMT
Server: Apache/2.0.50 (Linux/SUSE)
Set-Cookie: JSESSIONID=4972fadf-7681-4230-00bf-f68af2e8fed3.qa1-za; Path=/
Content-Length: 1859
Keep-Alive: timeout=15, max=100
Connection: Keep-Alive
Content-Type: text/html;charset=UTF-8

but if you access the same page through an intermediate cache (in this case squid 2.5), the login page (instead of the actual once-authenticated page) may be cached, e.g.:

see these headers:

HTTP/1.0 200 OK
Date: Wed, 28 Jun 2006 14:03:57 GMT
Server: Apache/2.0.50 (Linux/SUSE)
Content-Length: 1859
Content-Type: text/html;charset=UTF-8
Age: 79
X-Cache: HIT from cache1.uct.ac.za
X-Cache-Lookup: HIT from cache1.uct.ac.za:8080
X-Cache: MISS from cache.uct.ac.za
X-Cache-Lookup: MISS from cache.uct.ac.za:8080
Proxy-Connection: close

This can lead to 'false' authentication prompts, as the browser presents the cached login page instead of the actual site page from the portal.

The solution is for the portal to add a Cache-Control http header to the page when sending the login page, e.g. like this (from calendar):

response.addHeader("Cache-Control", "no-store, no-cache, must-revalidate, max-age=0, post-check=0, pre-check=0");