1

There's a website where a person should pay to get some service/product. After a person has made a reservation/product by paid for it, I want to allow him to track the progress without having to or register or login. It'll be similar to page on airline website where one can enter their last name and the number of reservation and see its status.

I'm confused at how I should ask for a person's email and the number of reservation: by GET or POST. That is,

1) should I create 2 text boxes on "show_reservation.html" and require a person enter them -- POST.

2) or should I email them a direct link with their email and number of reservation in the url: show_reservation.html?email=abc@example.com&reservation_id=1234abcd -- GET

?

There're advantages and disadvantages of each approach. Which one would you recommend?

In any case I'll need to email him either a full url or reservation number and the link to the page.

|improve this question
  • Well the first one seem far simpler for both the user and for you, so if you don't have any good reason to do it differently, choose that. Of course if the requirement is that the user should be able to return later this approach wont work. – JacquesB May 13 '18 at 12:38
  • How troublesome would it be is someone else gets hold of the combination of email and reservation number? Could that leak information that is only supposed to be shown to the rightful holder of the reservation? – Bart van Ingen Schenau May 13 '18 at 16:38
  • @BartvanIngenSchenau leak of personal information, can be troublesome – Ivanari May 13 '18 at 17:45
  • @Ivanari: Then you should take into account that request/URL parameters (like in the GET example you gave) are typically logged by various intermediate servers that the request passes through. At least some of those servers will not be under your control. – Bart van Ingen Schenau May 14 '18 at 10:18
0

There are three independent issues here:

  • what data the customer must supply to get his information (his access token)
  • how you communicate the access token to the customer
  • how he communicates the token back to you

E-mail address plus a (probably small) integer makes a very bad access token because they are easily guessed by a hacker. You should generate a unique token that's essentially random and long enough to be unguessable and unrelated to any personal information. If you use an unsecured channel (normal e-mail, unencrypted web page) to communicate the token, you can't really guarantee protection of private data anymore. Sadly, almost nobody is using secure e-mail, so this is almost never an option. If you want to have a safe solution, you can provide the access token on some kind of checkout page that would be https encrypted, or send it to the customer via postal mail if you can't provide it immediately. The third issue is actually a non-issue when sending an URL via unencrypted mail is not advisable due to privacy concerns. If the customer gets his access token on a web page or via snail mail, he will most likely enter it into an input field manually, so POST is a natural choice there.

|improve this answer
  • the question isn't about how strong an access token should be. – Ivanari May 14 '18 at 13:38
  • Sorry, you're right, I was put off track by the discussion. So if transport security in both directions is not an issue, the trade-off is between having a localized information leak in your server's log files when you use GET, and more cumbersome and error-prone user experience when you use POST. If you can trust your server admins, GET is much nicer to the user... – Hans-Martin Mosner May 14 '18 at 14:03
  • even if I was the admin of the website, when using GET the query string would still appear in the logs of my provider or somewhere else. – Ivanari May 14 '18 at 16:09

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.