TTL index for users collection

Question

I have 'users' collections with the following structure:

_id: ObjectId(...),
name: 'Erik',
email: 'erik@mail.com'

I need to use signup confirmation via email, so I need yours advice for the following approach:

• Create TTL index on that collection for confirm field:

  db.users.ensureIndex({"confirm": 1}, {expireAfterSeconds: 60*60*1000});
  

• When user sign up, then create this one with confirm as current time:

   db.users.create({name: 'name', email: 'email', confirm: new Date()});
  

• When user send request for confirming your account we update his confirm field to true because we don't want that user to be removed by TTL index:

  db.users.update({email: req.param('email'), {confirm: true}});

I want know the following:

1. Is the approach above correct.
2. Is the approach above secure

Answer 1

Regarding correctness: According to the documentation, when the field indexed by the TTL index is not a valid BSON date, the document will never expire, so setting it to true would prevent it from expiring. So this would work. But keep in mind that when the document is expired it will disappear without a trace, so you have no way to tell if the user who tries to confirm expired or never existed in the first place.

But there is an error in your update command. Besides the fact that you placed a closing } wrong, this update will replace the whole document with a new one containing only the field confirm:true. When you want to keep all other fields of the document, use the $set operator:

db.users.update({email: req.param('email')}, {$set:{confirm:true}});

Also keep in mind that this update will only work reliable as long as the email field is unique, so make sure you have an unique index on email.

Regarding safety: TTL is implemented as a background job which is scheduled every 60 seconds and deletes all documents it finds expired. This job is low-priority, so the database can postpone it when it is too busy. That means that you can not rely on the expiration happening exactly after 1000 hours, but my guess is that accuracy isn't that important for your particular use-case.