Attendee Content

[Alex Steer]

I want to create some content that is only accessible to confirmed ticket holders but I am not using the users functionality of WordPress.
My initial idea for doing this is to create a password protected page which requires the attendees email address (using attendee question) for the user name and the ticket number for the password.
Do you know of a better way that this could be done – or even how I could pull the two fields to make the credentials?
Many thanks.

[Stephen Harris]

Hi Alex,

My advice would be to use the WP Users.

There are numerous problems with user password protected pages:

1. They are not very secure (the password is kept in plain text in the database). I do not know the original motivation for WordPress to allow pages to be password protected, but it doesn’t appear to have been implemented with security in mind.
2. A password protected page doesn’t have a username, just a password, and has only one password. (You mentioned the user using their email address as the username and ticket number as the password).

You don’t mention how important it is for non-attendees to gain access to the content, so (1) might not be an issue. (2) is as you have only password, and so you cannot revoke access from an attendee.

With a bit of development you could implement something similar to what you suggested. Essentially you would:

1. Create a password or unique (unpredictable) URL for each attendee
2. On visiting the page ask for the user’s e-mail and password (or use the URL). The difficulty here would be if the attendee has multiple tickets for different bookings/events – which password should they use? Any? If it matters, you can ask for a booking reference number too.
   1. Extract the stored hash of the password associated with that ticket and compare against the given password (if you answered ‘Any’ you would have to pull out all passwords linked to that e-mail and try each one)
   2. If valid, check the status of the associated booking and allow them to see the content (you’ll probably want to set a secure cookie).

That’s quite a body of work. If its not impossible to utilize WordPress’ native user accounts you could simply:

• Create an account for ticket holders (if they don’t already have one).
• Store a reference to their ticket ID in user meta
• Require users log-in to see the protected content
• Display the content if the current user has a ticket associated with an appropriate booking.

You cut out the steps of having to securely store a hash, password management and authentication.

[Author]

Posts