PDA

View Full Version : Confirm iPhone user




SimonBS
Apr 9, 2011, 06:04 AM
Hi,

I have developed an iPhone application for a café. In the application you can order takeaway food and therefore I need a way to be sure that there are no orders in a "fake" name (e.g. a person who makes an order with a strangers name, e-mail and so on)

Therefore I have to make the user confirm the order before it's sent to the café. I am not sure what the best way to do this is.

I have been thinking of setting up an SMS gateway and when an order is placed, an SMS is sent to the the entered phone number and the user will have to send a confirmation SMS back. I am not a fan of this approach, as the confirmation is not happening in the application itself.

Then I got the idea that this might be possible with push notifications. I am not exactly sure how it would work (if you have any ideas on this, please let me hear) but since Apple writes the following in their documentation I do not really dare to rely on this for confirmation.

Important: Because delivery is not guaranteed, you should not depend on the remote-notifications facility for delivering critical data to an application via the payload. And never include sensitive data in the payload. You should use it only to notify the user that new data is available.

Another approach which would be very easy to implement would be to programtically retrieve the user's phone number from the SIM card but I have read that Apple rejects applications which does this.

I would like to ask if you have any ideas how I can do this confirmation? It could be one of the above approaches or a completely new. Would it be possible to do something with the unique ID that the every iPhone has?



dantastic
Apr 9, 2011, 07:29 AM
I suppose that is a risk you are always taking. Someone could phone in an order and not pick it up.

Accepting that I'd set up a blacklist. Record the ID of the device and if they are a no-show just block that device. Maybe as a deterrent display a message saying that you are logging the device ID.

On launch then have the app check if it's on the blacklist and display an alert and they would have to come in to the shop to be removed from it.

I think this is the best compromise. You don't want to hassle genuine customers with too much verification.

bredell
Apr 9, 2011, 02:02 PM
I'm not sure this will work but I might be worth trying. If you register your own URL scheme with your app you can send confirmation SMS messages to the customer containing a URL link. When the customer clicks on the link, your app is started and the verification is complete. That would make the SMS confirmation a lot easier. Perhaps you could use SMS verification the first time a customer is placing an order, when the order is complete you register the phone UUID so that the customer doesn't have to use the SMS confirmation for his next oder.

Another approach would be to require registration codes. The café could give these registration codes to customers that visit the café in person, the customer can use this code to activate the ordering function of the app. This would make the ordering function useful only to those customers that have visited the shop in person. To avoid having to use a database with registration codes you can use an HMAC embedded in the code that validates it with the phone.

SimonBS
Apr 10, 2011, 05:26 AM
I suppose that is a risk you are always taking. Someone could phone in an order and not pick it up.

Accepting that I'd set up a blacklist. Record the ID of the device and if they are a no-show just block that device. Maybe as a deterrent display a message saying that you are logging the device ID.

On launch then have the app check if it's on the blacklist and display an alert and they would have to come in to the shop to be removed from it.

I think this is the best compromise. You don't want to hassle genuine customers with too much verification.

The blacklist idea is actually pretty good and also easy to implement. Also, you are right that "good" customers should not be irritated by the confirmation. This could be a solution!

I'm not sure this will work but I might be worth trying. If you register your own URL scheme with your app you can send confirmation SMS messages to the customer containing a URL link. When the customer clicks on the link, your app is started and the verification is complete. That would make the SMS confirmation a lot easier. Perhaps you could use SMS verification the first time a customer is placing an order, when the order is complete you register the phone UUID so that the customer doesn't have to use the SMS confirmation for his next oder.

This is not a bad idea but still, I am not fan of using an SMS gateway, though it seems to be the most secure approach. I am not sure if any SMS gateway would allow me to store such data - but I haven't really read up on that. It should be possible.

Another approach would be to require registration codes. The café could give these registration codes to customers that visit the café in person, the customer can use this code to activate the ordering function of the app. This would make the ordering function useful only to those customers that have visited the shop in person. To avoid having to use a database with registration codes you can use an HMAC embedded in the code that validates it with the phone.

Well, this would be a way to do it but we would like that the users are not forced to have been to the café. You know, if you friend says "This café is great!" it is awesome if you could just pull out your iPhone and start ordering for the first time :-)