None of the email check routines from 113 to 142 uc_cart_checkout_pane.inc work to stop an existing email from being used and changed as to user info in anonymous checkout.

Instead the card will process and give a message "we found an existing email address and attached the order to that address"

Allow anonymous checkout, checkout review and create an account on checkout are set.

If a new email address is used -a new account is created by the email first part as a username and password are included in the emailed invoice, but the account does not have a "my account" or "account" or "name of user account" link in a menu when logged in - so perhaps user.install does not run

Comments

TR’s picture

TR CreditAttribution: TR commented
Status: Active » Postponed (maintainer needs more info)

Your first sentence doesn't make sense. I don't understand what the issue is - you seem to be describing intended behavior, except for the missing links which also doesn't really make sense. Please give specific steps to reproduce what you see and describe what you expect to happen as well as what actually happens.

bobburns’s picture

bobburns CreditAttribution: bobburns commented

Looking at the code in uc_cart_checkout_pane.inc it looks like there are supposed to be a number of email address checks - one of which being if the email existing is belonging to an account holder and they are not logged in then the warning should be presented to log in - which I would guess before any further progress in made in the checkout

It does not do this and instead does what the issue says - lets the order go through and then attached the new order and address and name to an another's email - who was never logged in.

That is NOT what the documentation in the code says is "intended behavior"

If a credit card was on file -an anonymous user could use it and have the order shipped then to them

The first line refers to check sub-routines (if code) and those are the lines where found in uc_cart_checkout_pane.inc

TR’s picture

TR CreditAttribution: TR commented

Well of course the code gets executed, but what it does depends on the many settings you will find at /admin/store/settings/checkout. When you say "warning should be presented", that's only for certain combinations of settings. We do have SimpleTest test cases which check to see that these settings do the expected thing. So until you detail your settings and say exactly what you expected would happen with those settings I'm pretty sure it's doing what it's supposed to - the situation you describe *is* one of the possible behaviors, so it just sounds like your settings are such that you're using this behavior.

There is absolutely NO security problem with what we're doing here. This was discussed in detail 4-5 years ago when this behavior was first introduced. It also went through a Drupal security team review. There's no way an anonymous user can charge an order to a registered user's credit card. I'm not going to rehash that discussion here. Search this issue queue and ubercart.org for the details if you're concerned.

bobburns’s picture

bobburns CreditAttribution: bobburns commented

You are right - I found the second box checked for this behavior under anonymous checkout. I do not see how anyone would want this as a feature - it invites friendly fraud charge backs.

I will close that as "works as designed"; however,

Through Stripe under a recurring payment system - or storage as a customer with a card on file - it is possible using the email to charge the card on file and under fraud checks possible to attach a credit or velocity check case to another person's email address - because in testing I did it

I am curious how a Drupal Security Team arrived at that clearance in their review - but das macht nichts . . .

Now that i am able to turn this off - and the code I saw back on - my concerns stop there

bobburns’s picture

bobburns CreditAttribution: bobburns commented
Status: Postponed (maintainer needs more info) » Closed (works as designed)

Fixed - works as designed