ChiliProject is not maintained anymore. Please be advised that there will be no more updates.

We do not recommend that you setup new ChiliProject instances and we urge all existing users to migrate their data to a maintained system, e.g. Redmine. We will provide a migration script later. In the meantime, you can use the instructions by Christian Daehn.

Forums » Develop »

Cache-Control headers

Added by Steffen Gebert at 2011-11-23 09:10 am

Hi,

as we are moving our pretty large redmine to a faster server, we are considering some further options to give it even more speed boost.

We think of a varnish or nginx proxy in front of it, which caches at least anonymous access for few minutes.

The only thing I found was redmine issue 7204, which leads to a github project Redmine_cacheable_pages
However, this does not sound very clean and by reading his omments I'm not sure that the author is confident in what he's doing (but I can't judge, as I'm also not a ruby developer).

Are you planning anything like this? This would be a huge advantage over redmine and we would very likely finally switch to ChiliProject.
There is (almost) no point in cache-control: private and setting a cookie, if nobody is logged in. The amount of bots we have on our current site is so immense that they are totally blocked, as they bring the server on its knees - which is a really bad choice.

Looking forward to your ideas!
Steffen


Replies (2)

RE: Cache-Control headers - Added by Moritz Breit at 2011-11-23 12:14 pm

I was wondering why there is a session cookie for anonymous users as well, so I looked into the ChiliProject source. I am not a ChiliProject developer, but however here are my results for discussion:

The cookie gets created because of the Rails CSRF protection. This creates an authenticity token which is stored in the session (which needs the cookie) and in the html code.

I have created a branch on my Github account which disables the CSRF protection as long as the user is not logged in. This branch is just a prove of concept and only for testing purposes.

https://github.com/mbreit/chiliproject/commit/1ed60dbf4662dd98065aa1be504686ec7162ad84

I am not really sure if this has no security implications, but an anonymous user should not be able to do security relevant actions where CSRF protection is needed.

Notes:
  • This does not prevent the session from being created when some controllers store values in it (for example it will be created on the ticket page where the current query setting are stored in the session).
  • My commit does not change the cache-control header.

I would also appreciate some feedback from the ChiliProject developers as I think that it would be great for public ChiliProject sites to get rid of the session cookie for anonymous users.

RE: Cache-Control headers - Added by Eric Davis at 2011-11-25 10:17 am

Steffen Gebert wrote:

There is (almost) no point in cache-control: private and setting a cookie, if nobody is logged in. The amount of bots we have on our current site is so immense that they are totally blocked, as they bring the server on its knees - which is a really bad choice.

You can't assume you can cache pages for anonymous users. Depending on your permission configuration, you can give anonymous users write access. Which means an anonymous user could edit a page and then the page would get cached with infomation that shouldn't be cached (e.g. the "Issue updated" message).

Moritz Breit wrote:

I was wondering why there is a session cookie for anonymous users as well, so I looked into the ChiliProject source.

Same thing as above. If your permissions allow anonymous edits and you turn off CSRF then you would be vulnerable to those attacks.

Eric

(1-2/2)