Designing a PHP script/functionality with future and safety in mind

[Ortix]

[i asked the exact same question on stackoverflow, but I like the people here better]

I have a project i'm working on with a **very** weird request from my client, which I need some help with since i'm not quite sure how to handle it. This is all done in Joomla and PHP 5.3

The company i work for sells ankle braces. They will be placing ankle scanners across stores which scans the ankles. After that the scanner will send you to the online webshop through its integrated screen. The idea is that you simply enter an email address and the system automatically logs you in on the webshop with an automatically generated password. You can run through the customization options and place an order.

So there are 2 scenarios. If the email (which is also the username) does NOT exist, it is created and logged in. This works fine. The user can place the order and later on change the automatically generated PW.

However what if the user exists? Our "solution" was to create a ghost account with a simple timestamp appended at the end of the email. The user to whom the existing email belongs to will get notified.

If it was him/her in the store "logging in", then that user can MERGE the ghost with the existing user. It will basically re-associate everything with the existing user.

If it was some prankster, however, the account will be deleted in 48 hours or something along those lines.

However I have no idea how to handle this situation. This is so not common and I don't know what to do.

[Csharp]

To me it seems there is a flaw in this idea. When does the user provide you with payment details for his order? And when does he tell you where he wants his order delivered?

[Ortix]

I said the same thing, but the client insisted on logging in with just an email (ARGHHH).

 

The payment and shipping details are provided then and there in the webshop on the scanners integrated screen, but the user can also finish the order at home and stop anywhere in the process. Perhaps the ordering has to be done at home in the case of a "ghost" account being created. So if the account exists, the customer can only finish the order once the account has been merged? Unless you (or someone else) as a better solution to this problem.

Edited June 21, 2013 by Ortix

[gizmola]

The entire ghost account idea is a waste of time.

 

What benefit does someone derive from entering someone else's email while providing their own identification and payment information?

 

The email address is irrelevant as email does not identify a person for the purposes of payment. It seems like you're concerned about a problem that doesn't exist.

 

What benefit do I get from giving out the email of someone else, and then providing my own identification and payment information? Is it to help someone else defraud me?

 

Truthfully, this sounds like such a mind bogglingly stupid premise I'm wondering if there's not something lost in the translation here?

 

I don't understand what the "scanners" are actually scanning? What information is on the "braces" (bracelets?) and how does that figure into this process? If you have 10 customers in the store at the same time, what happens?

[Ortix]

The entire ghost account idea is a waste of time.

 

What benefit does someone derive from entering someone else's email while providing their own identification and payment information?

 

The email address is irrelevant as email does not identify a person for the purposes of payment. It seems like you're concerned about a problem that doesn't exist.

 

What benefit do I get from giving out the email of someone else, and then providing my own identification and payment information? Is it to help someone else defraud me?

 

Truthfully, this sounds like such a mind bogglingly stupid premise I'm wondering if there's not something lost in the translation here?

 

I don't understand what the "scanners" are actually scanning? What information is on the "braces" (bracelets?) and how does that figure into this process? If you have 10 customers in the store at the same time, what happens?

 

Let me try to explain better. The scanner first of all scans the ankles. These braces are ankle braces. They are custom products which need to be 3D printed once an order has been paid.

However let's look at this example. I have created an account on the website from my home PC. I then decide to go to the store to get my ankle scanned. I then need to bind that scan to my account. The big boss wants the only authentication method to be an email address (which is also the username). So what happens now? I go to the store, scan my ankle and then enter my email. I can't possibly log someone in without a password. I could however create the "ghost" account which acts as a temporary bridge.

 

But I know this idea is flawed, because there is a shitload of stuff that can go wrong when trying to merge accounts and it's just a pain in the ass to work this way. I just can't think of any other solution. I'll try to convince the client to have existing users log in with their password and new users can just create an account with only an email.

Edited June 22, 2013 by Ortix

[kicken]

I'll try to convince the client to have existing users log in with their password and new users can just create an account with only an email.

Either that, or just accept the fact that it is going to be a lax security setup. Unless you are doing something like allowing a user to store their credit-card info and automatically charge things, I don't really see that much of a problem with making an email address the only requirement for login at the kiosk. You could just set it up to allow a new scan but nothing else unless they login with the password also.

 

The two most likely scenarios of someone entering an email which is not their own are going to be

1) They are sharing a friends account. This will happen whether you require a password or not. Or

2) They typo their email and it just happens to match some other user's email. While possible, this is probably unlikely to happen. Even if it did, I see no real harm in it.

 

 

Without knowing all the requirements the client wants, the direction I would go is probably a two-option approach:

1) Login with email only: A user can place a new order or attach a scan to an existing order. Any other access is not allowed

2) Login with email + password: A user has full account access and can do things like view order history, access personal information, place an order using save payment info, etc.

Edited June 22, 2013 by kicken

[Csharp]

I said the same thing, but the client insisted on logging in with just an email (ARGHHH).

 

The payment and shipping details are provided then and there in the webshop on the scanners integrated screen, but the user can also finish the order at home and stop anywhere in the process. Perhaps the ordering has to be done at home in the case of a "ghost" account being created. So if the account exists, the customer can only finish the order once the account has been merged? Unless you (or someone else) as a better solution to this problem.

 

So if the client can add all of his personal data into the machine... Why can't he also choose a password to authenticate himself later?

[Ortix]

I eventually managed to convince the big boss with some solid arguments about user friendliness, safety and future complexity. This stupid idea is off the table and I can sleep at night without feeling guilty of bringing such a crippled application to this world. Off to programming