文档中心 > 基础技术

 改造内容

本次改造内容分为两块,第一是子账号sessionkey的改造;第二是子账号授权模式的改造;

 ①. 子账号sessionkey改造,影响主要面向ISV(第三方应用开发者)

  •  改造前:子账号登陆获取的授权码sessionkey值跟主账号的一致;
  •  改造后:给子账号颁发重新生成的sessionkey值,与主sessionkey相关但参数值不同, 子sessionkey授权时长与主sessionkey一致,支持主子sessionkey各自独立刷新高危读写API的有效时长,子账号授权方式和返回参数解析不变,子账号通过配置授权应用的权限之后  均可授权给应用;

②. 子账号授权模式的改造,影响主要面向用户;(请点击改造后用户子账号授权流程)

  • 改造前:支持所有子账号对第三方应用的访问权;
  • 改造后:可支持通过岗位授权第三方应用或针对个别子账号单独授权第三方应用;

改造范围

只要支持子账号的应用都生效;(本次改造暂不对旺旺插件类应用生效

改造目的

对用户来说:

①. 保护用户数据安全;后期会在api层面根据不同权限不同子账号sessionkey限制api权限(还在规划中);

②. 多个应用使用一套账号系统;一个卖家会使用多个isv的系统,如ERP、CRM等,可以使用一套子帐号系统;

③. 分岗位分员工使用系统;卖家主账号可以根据员工权限和岗位决定是否给予系统使用权限;

对ISV和商家来说:

①. 日志监控;使用子账号的sessionkey,便于记录操作源头,做安全日志监控;并且官方会统一开放操作日志供用户查询,进一步记录到最准确的操作者; (目前官方记录的操作日志都是基于父帐号的,因为子账sessionkey就是直接使用父帐号的,改造之后会做成继承子sessionkey的控制);

注意:

日志查询入口:在子账号管理系统的“操作日志”中查询;

监控业务范围:主要是几块核心的业务,如商品、交易等的修改、删除等操作,所以监控的API只有部分高危的API;

监控对象范围:所有支持子账号并调用修改价格等高危监控的API的第三方应用,以及淘宝后台相应操作记录;

日志开放内容:只记录行为,不记录具体的API,具体到操作者nick,时间,appkey(若是第三方应用),操作内容等;

 

子账号sessionkey生效规则

  • 子sessionkey与主sessionkey的授权有效时长相等,当主账号sessionkey失效时,子sessionkey也同样失效;子账号无法授权需给予提示;
  • 主账号在“子账号管理”中取消对某子账号的授权,则该子账号的所有外部sessionkey均失效;子账号无法授权时给予提示;
  • 在子sessionkey有效的前提下,主子账号都可各自刷新其R1、R2、W1、W2四个时长,且相互不受影响;(详见平台安全等级);
  • 子账号首次授权、短授权验证需弹出授权页面,无法授权成功需提示原因。

 

子账号sessionkey颁发规则

    老授权方式:TOP授权大开关,控制所有子账号可用或不可用。

        针对老授权方式:将取消TOP给子账号授权的大开关,两个入口取消:

               1.  TOP的授权页面,取消授权子账号的勾选框,如图(1);

               2.  账号管理中的应用授权页修改,取消下图红框中的功能,如图(2);

 

 

图(1)

 

图(2)

     新授权方式

          子账号在子账号管理中配置对应的应用之后,子账号进入登入授权页面 进行授权即可。 

具体参考子账号授权流程介绍(新) 及用户授权文档。

子账号授权体系

 

l  基于OAuth2.0的登录验证授权方式(官方推荐使用):用户授权 (对于用短授权的API建议使用该授权协议);

如何知道当前用户是否是子账号?通过解析返回的json格式,解析返回有sub_taobao_user_id和sub_taobao_user_nick。具体方法看上述用户授权文档

 

ISV操作过程建议

 后台定时轮询操作

 针对应用实现的定时订单下载、定时商品上架、定时库存更改等功能操作,可以保持使用缓存在本地的主账号sessionkey,

为一旦子账号关闭或过期,该子账号的sessionkey都会失效,导致应用定时功能无法正常进行;

 

日常操作

对于日常的操作功能,如价格修改,属性修改等,官方强烈建议根据当前会话者的sessionkey来作为调用根据,特别是调用到高危api(删、改操作的操作;官方以后会将高危的API写的操作做成继承子sessionkey的控制,相关的操作记录会记录到对应的子账号,做到最准确的安全监控(这部分官方日志信息以后会统一开放);

 

 单app单sessionkey

对于商家后台等自研使用型应用,开发者一般程序设置是写死appkey,接受一个sessionkey(父帐号sk),子账号授权码改造后(不同子账号不同sessionkey),支持多个子账号的帐号系统应用需要设置接受多个sessionkey,避免多个账号登陆出现排挤下线现象;

 

 及时判断sessionkey是否有效

  • 对于本地保存sessionkey形式的,建议用户每次登陆后将当前返回的新sessionkey与本地保存对应用户老的sessionkey做对比,如果不一致,要用新sessionkey覆盖老sessionkey,保持sessionkey的有效性;因为淘宝子账号在欠费、停用、主账号取消过某个应用的授权、W2过时未重新登陆、R过时未刷新的情况下,对应子账号的老sessionkey就会失效,之后重新使用,会重新颁发新sessionkey;

 

  • 不保存在本地,每次用户登录获取当前sessionkey使用;(推荐使用)目前TOP的授权系统,在sessionkey没有失效前,每次登陆会直接进入系统并返回同一个sessionkey,若失效或sessionkey时长过期,之后登陆会重新跳转到授权页面并返回新颁发的sessionkey,所以采取使用当前登陆返回的sessionkey永远是最新的;(对于使用父帐号后台定时轮训操作的功能,还是建议保持父帐号的sessionkey保存在本地)

 

FAQ

关于此文档暂时还没有FAQ
返回
顶部