Security concept for guest account

[prinzdezibel]

ATM, a guest account is a completely open and unsecure thing.

Everybody can create a new login token with any email address he likes to. With that token he can view all the data assciated with this account:

Could be:

• Transaction history
• Orders
• Shipment addresses
• etc, etc

We need a concept how to deal with that. Some quick flash-lights:

• Don't publish any data to the client that is connected to a guest account

• eMail verification of created token

  a) Every time the user logs in (as guest)?
  b) Only The first time? But then, how to be sure that the user has the given email address the second time anybody tries to log in as guest with that email address?
  c) Use the login token from users browser for subsequent guest logins? (At the moment we just create a new guestLoginToken)

[aaronjudd]

I think a guest account should have access to any "order" data, but without a password set it's just the specific order confirmation (not general account data), and only on while on a browser that has a valid guest token for the created order.

We should prompt to create a password on the order confirmation page (and that would finish converting the guest to an account).

We could send a login link to guest account that sets browser + session token, to review order details. (something like: check your order status here: link). This could be just a link in an order confirmation email. Whatever page it links to should have the opportunity to convert to an account by setting a password. Not sure if this should be tied to the specific computer/ip that created the order or not (if the email has been forwarded, can that person set the password, or lean towards the user might not care and has intentionally forwarded, and would rather see on a various machines).

If a user attempts to sign in to the guest account, or use the email to create an account that doesn't have a password, email them a set password link.

Without an account, the user should not be able to change order details or any other account information.

[prinzdezibel]

I haven't completely digested it yet. This is the situation: Person A does checkout as guest with eMail [email protected] and ends with "order placed". Person B does also login as guest with the same eMail [email protected]. They both get a different guest token, but both tokens are tied to the same account. Therefore Person B may read the placed order from Person A.

Maybe it would be a good thing to tie the Order object to the login token for guest logins?

@aaronjudd Does this match your idea above or were you thinking differently?

[aaronjudd]

I think I have another (additional) approach. I'm suggesting that we modify the cart methods, and specifically copyCartToOrder to not validate the user Id, a session id being enough.
then add functionality to:

    ###
    # todo: implement guest checkout here.
    # save sessionId to cart collection
    # if this guest sessionId becomes a user
    # or if an email sent to the user confirms sessionId belongs to this email
    # it can be reconnected to any user account where the email is registered.
    # we won't validate user account here further
    ###

Or maybe to resolve your "They both get a different guest token, but both tokens are tied to the same account." problem (yeah, that's valid).. maybe there isn't a way for a user to connect accounts unless they register on the same machine. The sessionId could still be there for admin actions on that, or other processing later.

[aldeed]

Just reading through all these discussions again, and I'm wondering if you're overcomplicating things by trying to fit a square guest into a round user. It was my first inclination, too, but the various possibilities for confusion seem scary, from a security and maintainability perspective.

Here's my alternative thought:

1. Add optional email property to cart/order doc.
2. If checking out as guest, store the email there. userId property is blank.
3. Wherever code would otherwise look at the user doc (like when sending order status emails, etc.), use the order email prop if there isn't a userId.
4. When someone creates a user account, after they've verified their email address, look for that email in email prop on any past orders/carts. Clear the email prop and set the userId to the new userId.
5. After a guest order is placed, there is no linking token, no logged in state, etc. The browser cache is wiped such that there is no way to see anything about that order you just placed.
6. But there is some screen where you can request order details/status be emailed to you based on entering just an email address.

This might be similar to what @aaronjudd proposed in the previous comment, but I'm proposing that there is a point during guest checkout (maybe not until final submission, or maybe once address/payment info is entered, if we are concerned about the security of that info?) where we can forget sessionId and key off order email instead, without any user doc involved.

[prinzdezibel]

Agree with you, @aldeed. Seems like the guest role in this context just isn't a good match to be modeled as user doc.