时间:2021-07-01 10:21:17 帮助过:14人阅读
userid username password gender registertime loginnum registeraddress ip ...
userid nick figureurl api_supplier ip loginnum ...
因为,本地表与第三方的userid列值可能存在冲突,也不可能合并吧?!
因为,本地表与第三方的userid列值可能存在冲突,也不可能合并吧?!
要么在本地表的最前面加一个auto_increment的id列,但这样有些列因为用不到则可能浪费掉
本来是各自独立的系统,合并了就没有“第三方”了
每个API塔都有返回一个唯一值的,可以用他的这个唯一值区分,不一定要分表
本来是各自独立的系统,合并了就没有“第三方”了
我知道,问题是第三方登陆以后要分配一个session给它吧,如果与本地用户系统区分处理,岂不是又要增加一套程序处理?
每个API塔都有返回一个唯一值的,可以用他的这个唯一值区分,不一定要分表
如果只是引用第三方登陆,没有进行本地绑定,则这个“外来”账号没有本地积分、空间等数据。。。
变通一下啊,插入会员表啊,用户名就随机的,这样不就有账号了么
变通一下啊,插入会员表啊,用户名就随机的,这样不就有账号了么
谢谢,我知道,但总觉得有不方便的地方
有什么不方便?因为使用第三方登录的就用第三方登录,有些用户习惯用第三登录,,用绑定的时候是方便原有的用户或者想使用2种方式的用户使用的,还有一个因素是假如第三方的登录出现问题时,用户如果想登录还可以通过绑定的账号来登录,不会造成因为第三方登录不能登录时而影响了本站用户的使用
有什么不方便?因为使用第三方登录的就用第三方登录,有些用户习惯用第三登录,,用绑定的时候是方便原有的用户或者想使用2种方式的用户使用的,还有一个因素是假如第三方的登录出现问题时,用户如果想登录还可以通过绑定的账号来登录,不会造成因为第三方登录不能登录时而影响了本站用户的使用
不觉得要对程序进行很多修改昧?!
我先看看吧
我想好了,所有第三方api登陆都与本地user表关联绑定,用户通过第三方登陆时分配一个userid给他,user表最后增加一个thirdPartyAPIid,表示来源,当然,本地用户的这列值为null。这样就好处理多了。
user表
userid username email password ... third_party_api_id
id userid username email ... provider
呵呵,我告诉你的思路是没问题的,我做这个很久了,而且根本不需要修改程序的,就只是做好第三方接口登陆,给予与本地一样的cookie或者session就可以了
呵呵,我告诉你的思路是没问题的,我做这个很久了,而且根本不需要修改程序的,就只是做好第三方接口登陆,给予与本地一样的cookie或者session就可以了
多谢,就这么定了,我现在正在看各网站提供的第三方登陆接口说明。