1

Here's the setup:

  • secure forms turned on
  • empty template (there are no forms, nothing at all in the template)
  • EE 2.7.1
  • logged in/out (makes no difference)
  • empty exp_security_hashes table

Every time I refresh/load the empty template in my browser an extra hash is created in the exp_security_hashes table.

From reading the docs I understood the XID was only created for forms. Am I missing something?

Creating a new XID for every page load on the front end doesn't seem right! Maybe 'secure forms' should be renamed 'secure site'.

Edit: And this template creates two XIDs, one for the form and the other for the (page??). Each XID is different but sames session_id.

{exp:user:edit return="myprofile/success" form:id="form_2" screen_name_password_required="no" dynamic="off" }
<input type="text" name="username" value="{username}"/>
<input type="submit" name="submit">
{/exp:user:edit}

The XID for the page is never set to 'used' so is never cleared.

And it looks like the XIDs dont get cleared until ee()->security->garbage_collect_xids() is called once every 7 days.

I've raised this as a bug and await EE response, which Ill post here.

  • Did you reported this on bug tracker? – Robson Sobral Oct 8 '13 at 10:47
  • I was hoping someone could confirm the same issue before i raised the bug. – Lloyd Hill Oct 8 '13 at 17:46
  • I'm pretty sure that is normal behavior. Secure forms is enabled by default on the front end with 2.7, so it generates the XIDs because there could be anything from login forms to an add-on needing it on your page. – Adrian Macneil Oct 8 '13 at 21:27
1

Edit: heres the bug report response from EE

It’s really not a bug, but it would be nice if we could only generate it when needed- i.e., the template parser spots a form tag. The sticking point is ajax and how the lack of an xid would jam things up there.

I know this started the devs bouncing some ideas around, but at the moment, the behavior is expected. And to be clear, it’s always generated the xid on page load- so while it would be great if they come up with a way to reduce those xid inserts, it’s not adding new overhead.

The issue i see is xids are also being created for more things than just page load and forms, which dont appear to be 'used' and cleared, resulting in quickly increasing size for exp_security_hashes table.

My solution for now, is to just run this via a cron job every day

ee()->security->garbage_collect_xids()
| improve this answer | |
  • 1
    What exactly is the problem with having a large exp_security_hashes table? What is your definition of large? As long as it has proper indexes set on it, it should be able to handle at least a few million rows even on a basic web host. – Adrian Macneil Oct 10 '13 at 23:31
  • I get the impression its not an issue. So ok, Ill leave it as it is/was. – Lloyd Hill Oct 11 '13 at 0:34
  • Our hashes table often crashes due to being so big, and this breaks the website, so its an important issue to solve. – Laurence Cope Feb 21 '16 at 10:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.