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.

3
  • Did you reported this on bug tracker?
    – Sobral
    Oct 8, 2013 at 10:47
  • I was hoping someone could confirm the same issue before i raised the bug.
    – Lloyd Hill
    Oct 8, 2013 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. Oct 8, 2013 at 21:27

1 Answer 1

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()
3
  • 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. Oct 10, 2013 at 23:31
  • I get the impression its not an issue. So ok, Ill leave it as it is/was.
    – Lloyd Hill
    Oct 11, 2013 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. Feb 21, 2016 at 10:42

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

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