将移动应用程序用户与其在线个人资料联系起来的最佳方式是什么？
假设我有一个名为 X 的杀手级移动应用程序。我有很多用户，有些用户想要 X 的桌面版本。如何将我的移动用户个人资料与他们的新网站个人资料关联起来？我不想在移动设备上有用户名/密码，因为我的所有用户都在移动设备上并且已经拥有唯一的移动设备 ID。 我正在考虑在云端生成一个简短的 UUID，将其发送到设备，当用户注册网站时，他们只需输入他们的 UUID 和电子邮件。 这是最好的方法吗？有更好的办法吗？
Let's say I have a killer mobile app named X. I have lots of users and some users want a desktop version of X. How do I associate my mobile users profile with their new website profile? I don't want to have a username/password on the mobile device, because all of my users are on mobile and have a unique mobile device id already.
I was thinking about generating a short UUID in the cloud, send it to the device and when the user signs up for the website they just input their UUID and email.
Is that the best way to do it? Is there a better way?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
与 Google 的身份验证集成。手机会弹出并询问您要使用哪个（与手机关联的所有 Google 帐户中）。然后您的网站和/或其他应用程序需要能够处理 Google 的登录。
Integrate with Google's auth. The phone will pop up and ask you which (of all the Google accounts you associate with your phone) you want to use. Then you website and/or other apps need to be able to handle Google's sign-in.
尝试像 OpenID 这样的东西，其中您有一个 ID，可以与多个设备关联，因为它是特定于用户的，并且不会出现任何此类问题。
例如，我们在登录页面上实现了类似的功能。
Try something like OpenID, where in you have one Id which can be associated to multiple devices as it would be user specific and there will not be any issue as such.
For example, we have something like SO has implemented on it login page.
通过使用用户的唯一设备 ID，您可能会限制用户使用单个移动设备。 （当用户获得新手机/平板电脑时会发生什么？）如果您跨多个平台（例如移动、桌面和网络）提供服务，我认为要求用户名和密码并不奇怪。
另一种选择是利用另一个已经进行身份验证的平台，例如 Facebook Connect 或 OpenFeint。当然，它应该只是一个选项：不应该要求用户拥有这样的帐户才能使用您的服务。
By using the user's unique device ID, you potentially limit the user to a single mobile device. (What happens when the user gets a new phone/tablet?) If you are providing a service across multiple platforms, (e.g. mobile, desktop, and web,) I don't think it would be outlandish to require a username and password.
Another option would be to leverage another platform that already does authentication, such as Facebook Connect, or OpenFeint. Of course, it should simply be an option: users shouldn't be required to have such an account to use your service.