for our system we have "anonymous" users (users with no email address), and "known" users (users with an email address.
Apple does not expose the MAC address, the IMEI or the apple UDID of iOS devices to developers. their policies strictly forbid the use of hardware identifiers in apps distributed via the app store. Apple also strongly suggests that you verify all in-app-purchases from your server to prevent theft (and it's worth it, i see lots of attempted theft) so, given that our business wants users to be able to use 95% of the apps features without "creating an account" (sharing your email/password and some other info we ask for), and we use apple's receipt verification to check for fraudulent purchases, both the client and the server have to know about a particular application install. that gets us to where i am at today: - app launches and gets an OAuth token from the server (creates an end_user record on the server) (this OAuth token essentially becomes an application installation identifier) - app stores data about the user - server stores data about the user - later user may "login" which may be logging in to an existing account they made on another device (cause lots of apple device users have multiple devices) or a new user. in the login case we merge the activity of the user from before login. now if the business would allow us to require login before the user started the app, problem is solved.....but we would lose 50-70% of our new users daily. On Monday, February 11, 2013 9:01:40 PM UTC-8, Alec Taylor wrote: > > On Tue, Feb 12, 2013 at 4:29 AM, howesc <how...@umich.edu <javascript:>> > wrote: > > Thanks Alec, that will be a nice contribution. > > > > re my "special odd pain in the rear-end" login flow.....well we (the > > engineers) failed to sell that to the business. users can make > purchases > > via apple without a proper logged in account, and we need to track those > on > > the server. hence the anonymous user. it would be really nice if apple > > shared with us the itunes user ID on app launch, but they don't because > they > > believe that violates the user's privacy (and i kinda agree on that > point). > > So i'm stuck with an overly complex login flow. :( > > > > cfh > > How do you differentiate between different anonymous users? > > Are you looking at MAC address or other related IDs? > > It sounds to me that that's still an open problem. And that not > generating any ID but storing data in LocalStorage (or a cookie; or > whatever else: locally) would be the most secure way of confirming > accountability. > > Given an e-commerce scenario; on checkout the anonymous user would > submit their entire LocalStorage; which obviously includes cart. Their > shipping details and whatnot would include an email address, so create > them that profile; log them in; and email them their randomly > generated password. > > #problem=solved > -- --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/groups/opt_out.
