I have a website that lets users submit a form without having to create an account and log in. However, in order to keep users accountable for their submissions, the form requires them to provide their school-issued email address (which follows a known, constant pattern and can be used to derive the user's real name).

The process currently looks like this:

  1. The user submits a form with his email address and the main content he wants to submit. Both are stored on the server.
  2. The site sends a confirmation email to the user at the address provided in the form submission.
  3. The user clicks the confirmation link in the email, signaling the application to process the form's main content. (If the link is not clicked within a certain timeframe, the form's main content is purged from the server.)

Over time, this may grow inconvenient for frequent visitors. I would like to implement a "remember me" checkbox that caches the user's confirmation. With this implemented, after successfully confirming a submission once, subsequent submissions within a given timeframe would not require email confirmation at all.

The top priority is that users must not be allowed to submit things in each other's names. I don't want to implement this convenience unless I know it can be done without violating that priority. Can this be securely pulled off? If so, how?

  • The question is fundamentally flawed; "remember me" = account. You're asking for authentication & non-repudication; that means you've got an account, no matter how you implement it.
    – MCW
    Dec 16, 2013 at 16:33
  • @MarkC.Wallace Strictly speaking, yes. That's why "remember me" is quoted: I'm using the term loosely because I don't know the proper term (if one exists).
    – Maxpm
    Dec 16, 2013 at 16:34
  • You might check into federated ID. Allow the user to establish their identity elsewhere and use the authentication on your site.
    – MCW
    Dec 17, 2013 at 14:21

3 Answers 3


Depending on the type of submissions you are accepting your site would strike me as having a serious security flaw because you accept submissions without authentication. If Bob knows Alice's email address he could submit data in her name, so you cannot trust the source of any submission. Although you send a confirmation email many people (and I'm assuming as you are talking about a school it's young people) would probably click the email without a second thought. As a parent I'd be concerned if my kids' school had a system like that.

As for whether it is safe, the question is safe from what? Why would you be concerned about protecting an email address which anyone could guess if they know the email address' naming convention?

EDIT: If all you want to do it make it so a system remembers an email address just use a cookie, that will remember data for specific users, so it would work on shared equipment. Or you could simply tell the browser it's an autocomplete field, same effect. I'd keep in mind that kids share their computers often, it may more advisable to make them type it in every time so friends don't end up submitting in each other's names.

  • I'm not concerned about protecting email addresses; I'm concerned about exactly what you mentioned: people submitting things in each other's names. You bring up a good point about people clicking confirmation links without a second thought.
    – Maxpm
    Dec 16, 2013 at 16:24

Yes this could work.

The emailed link could direct the user to a confirmation page that asks the user to read their submission and confirm that it was them that wrote it. This would add an extra step rather than simply accepting the submission after the first click from the email link. Not infallible, but at least you have a process that requires an active participation in the website to authorise a content submission.

You could establish a session when the article is submitted, and make it a requirement that the email confirmation takes place from the same computer and browser.

In short the process would be as follows:

  1. User loads website and enters email address and content.
  2. User submits form.
  3. Session token is generated and stored on server and in cookie.
  4. User receives email asking to confirm the content post is theirs.
  5. User clicks email link and is redirected to a page that validates the token in the email link and checks that it matches the user that posted the content by the session cookie.
  6. User is asked to click a button on the site to confirm, and also has the option of remember me.
  7. If button is clicked, the flag to retain the content after the timeout is set.
  8. If not, the content will be removed after the timeout.
  9. The user posts more content and if the session cookie matches the email address and the remember me option was checked, the content is posted and the flag to retain the content is automatically set.
  10. If any of these are false the process from step 3 is repeated instead.

  11. User can choose to log out which will remove the session on the server and the cookie.

  12. If the user does not visit the site in a while, the system could expire the session automatically (optional, but recommended if users are using shared computer accounts).

The above assumes that remember me will only work on the particular computer account/browser that was initially used. This will guard against users submitting content under the identity of other known users.


It highly depends on the technical implementation of your site and idea so I don't think there is a definite answer.

But, in principle: - if you use a secure session handling mechanism, - put the timeout to a short amount of time (less than 5'), - make sure that a user can't click on a random link and submit the form with custom content, - make sure that nobody can replay requests - make sure that a user can't inject any code into the website ( like provide a command that modifies the user the email is sent to ) - and finally make it so that the cookies don't contain any useful information to a third party(no identifying information, just a random -non sequential set of numbers that link to some information about the user to your database and which ) then it could be ok.

In case you haven't, maybe you should take a look at the owasp top 10 document and the related reading list on how to avoid these pitfalls.

also, what GdD said

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .