Anonymous users see other anoynmous user's credit card details

Do you still need help testing this?

Could it be that the real bug to fix here is that anonymous shouldn't have a card on file? That sounds like it's just WAITING to be abused.

I don't see a problem with that. Recurring billing should be associated with a user account. It doesn't make any sense to try to associate a recurring billing plan with an anonymous user. Require the user to log in first.

So process the user registration first, then associate the recurring billing stuff with that user. Again, recurring billing associated with an unregistered user makes absolutely zero sense.

Agreee with #9.

So is this a won't fix?

#12 thanks for clarifying this and with that in mind I don't see why this patch can't be altered to be an 'option' in user permissions i.e
"Allow anonymous users to checkout with (Commerce Card on File) support"

Hmm, so finally got to reviewing this, and I don't see any problem with the immediate "quick fix" of just disabling Card on File functionality for anonymous users. That was the original intention, and it was just an accident of me testing only as a logged in user that left the hole open for anonymous users.

We can then have a follow-up issue that deals with restructure the submit process to allow for the creation of CIM profiles on checkout completion for and updating them to the user account as suggested above.

Adding my +1 vote to allowing anonymous checkout ultimately storing the card of file w/recurring as per larowlan's use case (fits mine as well).

Just to clarify before moving forward. The current plan is to

1. Patch to remove card on file for anonymous in this issue.
2. Patch to add the feature back in in issue #1553468: Allow anonymous users to complete checkout and then have their card details stored against the account created during checkout.

If this is the case, I'll gladly review this and set to RBTC and then move onto #1553468: Allow anonymous users to complete checkout and then have their card details stored against the account created during checkout. and provide help/support there.

To clarify, anonymous users should NEVER have card data associated. The "proper" way to do this is to first create the user account, and THEN associate card data to the newly created user account.

It's a minor nit, but there should be no reason to ever add the ability to associate card data with anonymous users.

Hi @cweagans,

I disagree with your assertion in #17. We allow anonymous checkout for orders because that order is tied to a particular session. In the situation of an outsourced PCI compliance method (such as braintree - https://www.braintreepayments.com/tour/pci-compliance), the card details are sent directly to their servers in exchange for the token. That token could be associated directly with that order until the checkout completion process is completed, in which case it's transferred to the new user ID much like what happens with the order itself.

From the time the CC information is posted until that checkout is complete, the server would still need to track that token against that session. Now whether or not it's done through the card on file module specifically versus another table is up for discussion.

And just to be clear: I'm specifically suggesting that it's an association of the external card reference against a session versus the card data with anonymous users. I realize there is still the issue of session stealing, so I will think about that more. But I feel there has got to be a way to do this without forcing registration first, and using the style of anonymous order objects being associated with the newly created user object post checkout seems to be the way to go.

I'm not saying that you should force registration first. You can collect all the data on the same form (user info, cc details, etc), and just change your processing order: create the user account first, then associate credit card details.

I don't think I've ever seen a website that was trying to sell me something that first asked for my credit card information, then later asked for my info to create an account.

It's always been either a wizard where I was first asked for personal info and to create a user account and THEN asked for credit card information; or a single page checkout form where all of the info was collected at once.

If I went to a website and clicked sign up, and the only thing on the page was a credit card details form, I would not put my credit card details in there, because that's shady.

What, specifically, is the use case that you're trying to address?

Hey cweagans,

Quick background: I'm coming from an ubercart background about to migrate to commerce, so I'm not sure it there are workflow differences. I know with ubercart the user wasn't created until one went through both steps on the same page (e.g. added billing, shipping, and payment information) and THEN went to the final page for review. The user account was not generated midway though the process without physically leaving the cart and then coming back.

We faced a couple work flow issues with that. The first was users were not getting automatically logged and had to go get there details in their email, which was another barrier to entry we wanted to avoid.

If the user account is created between cart/checkout and cart/payment (or whatever the url is), then I withdrawl my request for having card on file with anonymous users as it'll be taken care of that way during the checkout versus post checkout complete.

In the meantime, I'd be happy to review and mark this RBTC :)

Ok, so the initial patch is the one to be commited here, right? Looks good to me.

Related: http://s1l.org/automatic-user-login-anonymous-checkout

Confirmed that the patch does fix the bug. I was able to reproduce bug, and after patch, the anonymous credit card data no longer was able to be accessed as an anonymous user.

Attached is reroll without whitespace.

Thanks for the re-roll, commited.

Uploaded patch for Version: 7.x-2.0-beta5+3-dev