With the module enabled and anonymous checkout allowed, the checkout form shows the user the previous anonymous checkout's details.
This patch removes it.

Comments

Also need a rule here that fires on checkout after the fact to associate the card on file with the new uid of the user created by commerce for the user during anonymous checkout.
This will mean an order id reference field will be needed in the commerce_cardonfile table too, so we can associate the storage of the card with the order and update it later.
So in summary needed:
*New field in commerce_cardonfile table to store order id.
*New rules action to 'Update stored cards'
*New default ruleset to fire after anonymous order is assigned to the newly created user account - in order to link the card on file to the new account.

Do you still need help testing this?

Yes, still need help on this

Status:Active» Needs review
StatusFileSize
new1.05 KB
new1.07 KB
new6.63 KB

Here's the patch and associated new files - this includes the original patch and has tested successfully.
Had to rename inc files to .txt but you get the point.
Needs an update.php.

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.

If you don't let anonymous users checkout and store their details - you can't have anonymous checkout + recurring billing.

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.

What if the registration form is integrated with checkout (ie signup and checkout in one step).
That was my use case.

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?

If this is marked 'won't fix' you need to at least apply the patch attached to the original issue. This removes anonymous support from the cardonfile checkout experience (in the case where someone inadvertently allows anonymous users to 'access checkout' and has this module enabled).

Just to be absolutely clear this patch is not about recurring billing with anonymous users it's about allowing anonymous users to 'access checkout' that in turn results in their account being created - and the recurring billing being associated with that account.

#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.

Split new functionality patches into #1553468: Allow anonymous users to complete checkout and then have their card details stored against the account created during checkout.
Original patch (attached to issue) fixes the major security issue.

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 :)

Status:Needs review» Reviewed & tested by the community

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

Priority:Major» Critical
StatusFileSize
new4.74 KB

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.

Status:Reviewed & tested by the community» Fixed

Thanks for the re-roll, commited.

Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.