Forum OpenACS Q&A: Strange cross-caching of users

We were having problems with people knowing when they were logged in, and whether they were logged in as themselves or as someone else, so I added a notice at the top of our administration page indicating the user saying, "You are logged in as NAME."

Unfortunately, we're seeing some odd problems that appear to stem from overaggressive caching of pages.  The project manager just called to tell me that things weren't working, and told me that the system claims she's logged in as my employee.  When I went to double-check the problem, I also saw that I was logged in as my employee.

Perhaps the real culprits here are the respective HTTP caches at my office and at my client's ISP.  And luckily, she hasn't yet figured out that such problems, if real, would be a major security problem.

So I'm wondering if anyone else has ever seen such issues in OpenACS -- and if so, whether there are any obvious fixes for them.  I really hope that this is a local configuration problem, or one that I can solve by tuning my nsd.tcl file.

A quick fix is to set the appropriate HTTP headers in the sitewide master template.

Also, even if the pages are cached you cannot carry out
any operation that does a permissions check since the
session_id in the cookie will be correct even if the page
presented to the browser is wrong.

For example it's vulnerable to cross-site scripting attacks. (see here: https://openacs.org/forums/message-view?message_id=32835)

And you can still muck around with prefetched acs_object ids on -1 forms.

Or have these two gaping holes been closed?

I haven't seen a real solution to the cross site scripting problem. Even if you scrub all possible content from this site, you are still left with easy exploits. Just direct readers to a 'foreign url' that contains the malicious code. By malicious code, I mean an 'a' link that contains an 'href' that can execute an http request in the context of the user viewing the 'foreign url'. Another possibility is to send an html formatted email containing the exploit to an admin. For small communities, it wouldn't be hard to come up with good bait.

This is a huge HTTP/HTML/application bug, with no fix in sight.

If it's not proxies doing the cacheing, but your own OpenACS server, then once you know that for sure tracking down where things are being memoized or otherwise caches in OpenACS/AOLserver should be much simpler.

The deal is this: Neither AOLserver nor OpenACS sends Expires or Cache-Control headers.  And the URLs in OpenACS look like they should contain static documents.

Unfortunately, this means that my ISP's mandatory and invisible caching proxy caches them.  Even more unfortunately, I share a proxy cache with the graphic designer and the client with whom I'm working.

So we've had a fun time the last few weeks, with everyone discovering that they're logged in as someone else.

The real solution would be for OpenACS to put out "Expires" headers at the top of each page, or to set Cache-Control to private.

I'm going to mess with the templating system a bit in the next few minutes, so that we won't have such ridiculous caching problems.  (And if it helps, I'll submit a patch.)  But if anyone has any obvious suggestions regarding where I can put this in, or reasons why this is a bad idea, I'll be happy to listen...

I basically want the system to turn caching off for anything that lacks a .jpeg, .png, or .gif extension.  Under Apache, it would be pretty easy to do this.  Surely there's a way to configure AOLServer to output HTTP headers conditionally, no?  And if not, then perhaps I should put such code in the templating system.

The link that best explained to me how to control your cache was mnot.net. I don't think messing with the default-master would do much.

You should run a filter from your tcl/init.tcl file. If you don't want or care about controlling access to your images, just have the filter also return the file and skip openacs completely. You still need to also skip out of any trace filters.

Another option that takes care of the few details of programming is to use my VAT module. You would need an additional domain, or subdomain name for the image files in that case. However, I would guess configuration of my module would take about the same amount of time as writing the filter.

If you do change the domain name for the images, you could use a simple static webserver for them as well: thttpd or publicfile might work for you.

What does the community think of this caching scheme (based on Tom's suggestion):

ad_proc cache_control {conn why} {

    Control cacheing of images, static and dynamic pages.

} {
    set url [string tolower [ad_conn url]]
    switch -regexp $url {

        .gif$ -
        .jpe?g$ -
        .png$ {

            # Expire images after an hour.

            set seconds [expr 60 * 60]
            ns_set update [ad_conn outputheaders] Expires \
                [ns_httptime [expr $seconds + [ns_time]]]
            ns_set update [ad_conn outputheaders] Cache-Control \
                "max-age=$seconds"
       }

        .css$ -
        .html?$ {

            # Expire static pages after half an hour.

            set seconds [expr 30 * 60]
            ns_set update [ad_conn outputheaders] Expires \
                [ns_httptime [expr $seconds + [ns_time]]]
            ns_set update [ad_conn outputheaders] Cache-Control \
                "max-age=$seconds"
        }

        default {

            # Expire all other pages immediately.

            ns_set update [ad_conn outputheaders] Expires \
                [ns_httptime [ns_time]]
            ns_set update [ad_conn outputheaders] Cache-Control \
                "no-cache,no-store,must-revalidate,proxy-revalidate"
            ns_set update [ad_conn outputheaders] Pragma \
                "no-cache"
        }
    }
    return filter_ok
}

# Register the cache control proc.

ad_register_filter -critical f trace * /* cache_control

I've saved this as cache-control-init.tcl in the /tcl directory.

/Bart

Tom,

you are paranoid ;)! Yes, both ad_ procs are defined at that point. Like I said, I'm running this script at a (staging) site. The advantage of ad_register_filter is that you can see the registered filters from the monitoring package.

/Bart

The ability to use expr with the eq ne keywords is new though so you would have to use AOL >= 3.5, which allows you to use a real version of tcl instead of the builtin one.

The OACS recommended version of AOLserver is showing its age and we should be recommending the newest AOL. (of course acs-lang in the head won't work).

Jon, Tilmann,

I agree with you both. Yes, caching should really be part of the request processor. Especially since I made a small but crucial mistake in the above code. The cache-control filter should be registered as a postauth filter rather than a trace filter. A trace filter isn't executed till after the connection closes.

I hadn't noriced because ACS developer support had me fooled for a while as the cache control headers did show up in the request information of ACS developer support. Delorie has a cool HTTP Header Viewer to inspect headers of Internet accessible sites with.

There is a lot more to controlling caching than this simple script handles. Postauth filters for example, are run before the request processor and hence it is impossible to use [ad_conn] to find out if the request was for a static file or not. Robert pointed out some of the other short comings.

Which ever solution will be adopted I belief that it should be part of the request processor where it can better distinguish between content material (dynamic, static, image, content type, etc) and the appropriate action. The final solution should leave room for customization, e.g. cache some parts of a site longer than others.

/Bart

Regarding adding .pdf, .wav, .doc: When the request processor decides if to add the cache control headers, it's not necessary to keep a list of file extensions at all, the rp would decide based on wether it is serving an actual file from the file system or calling one of the handlers, e.g. the one for tcl/adp pairs.

I agree that it should be possible for individual sciripts to override the cache handling of the rp, for example if a custom last-modified handling was to be implemented in cr_write_content it should be able to call something like "ad_conn -set rp_output_cache_control_headers_p 0" to inform the request processor that it should not add the headers.

I'm not sure, but it's definitely happening. Here's an example from fetching our beloved logo on the openacs.org site:

$ telnet openacs.org 80
HEAD /templates/slices/openacs.gif HTTP/1.0

HTTP/1.0 200 OK
...snip...
Last-Modified: Tue, 29 Oct 2002 16:41:11 GMT
...snip...

Notice the Last-Modified header.

Then, if I follow it up with an If-Modified-Since and:

$ telnet openacs.org 80
GET /templates/slices/openacs.gif HTTP/1.0
If-Modified-Since: Tue, 29 Oct 2002 16:41:11 GMT

HTTP/1.0 304 Not Modified

This correct behavior is not just limited to URLs which map directly to a file in the file system. cr_write_content, which calls ns_returnfile for static content stored in the file system, seems to also honor the Last-Modified/If-Modified-Since directives, which is a good thing.

And I'm not suggesting to add this *instead* of Cache-Control stuff, since it's already there. I'm suggesting that some people may want to remove all Cache-Control stuff for static content and instead rely on the Last-Modified/If-Modified-Since "protocol", which guarantees freshness along with some measure of efficiency.

Perhaps reasonable default behavior might be:

• At the end of the request, check if there is Last-Modified header. (From what I can tell, this would imply the URL maps to an actual file or is static content being delivered by, say, cr_write_content as described above. It could also have been dynamically added by a script.)
• If one exists, then optionally add a configurable caching directive (30 minutes, 1 hour, whatever), if there are no caching directives already present.
• Otherwise, add the "no cache" stuff, if there are no caching directives already present.

Hope that makes sense...