Hmm; good point. On Wed, Feb 13, 2013 at 4:30 AM, howesc <how...@umich.edu> wrote: > 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> 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. > >
-- --- 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.
