Re: scaling issues with security_tokens

On Tue, Jan 24, 2012 at 1:22 PM, Micah Anderson <micah <at> riseup.net> wrote:
>
> I am having a problem with scaling squirrelmail because of the update
> frequency of the security_tokens. It seems as though a new
> security_token is generated and put into the database (via a REPLACE
> INTO userprefs) everytime a squirrelmail user does anything in
> squirrelmail... perhaps with some exceptions (I did not look that
> closely).
>
> This may not be a big deal when you only have a few users, but when you
> have 39k users, this starts to really hammer the database. It also makes
> replication a major pain because every single one of those userprefs
> updates results in a query written to the binary log that then needs to
> be replayed on the replication slave.
>
> I've set $max_token_age_days = 1; but that only affects how much data
> accumulates in the security_tokens, but it doesn't affect the number of
> updates.
>
> Besides turning these off, which does not seem like a good idea, could
> there be a better way to handle these?

You could turn it off and enable referrer checking.  Referrer checking
is a good alternative safety mechanism as long as you understand that
any users whose browsers do not send referrer information will not
have the benefits of this security check (such users would be
vulnerable to CSRF attacks, although it may be reasonable to argue
that users who know enough to turn off referrer sending in their
browsers are savvy enough to know such attacks when they see them).