BAE迁移到百度开放云BCE后AK/SK使用上的变化

先说说BAEdeveloper.baidu.comdeveloper应用、developer服务、BAE以及BAE扩展服务和AK/SK之间的关系

 

developer.baidu.com这个平台在后面的描述中简称为developer

先看图1:
图1

 

从图1可以看出在developer上一个开发账号可以拥有多个developer的工程,developer工程下面包含了BAE等各个服务,而每个工程都有自己的一对AK/SK。

这时在“工程1”下面使用BAE以及其他服务时,需要用到AK/SK地方都是需要使用“工程1”下面的AK/SK。所以对于BAE开发者来说,对于处于“工程1”下面的BAE应用无论在代码中使用的了BAE的扩展服务如公有的Mysql、Mongo 以及日志服务等, 还是使用了developer的其他服务如云存储、 云推送等时,都是统一使用“工程1”下的AK/SK进行认证。所以在开发过程中只要保证BAE应用的代码中的AK/SK同BAE所在的工程下面的AK/SK一致就能正确地使用各项服务。

同时,对“工程1”进行SK重置时,对于“工程1”下的所有BAE应用使用的AK/SK中的SK都要修改为重置后的新SK。

 

BEAdeveloper.baidu.com迁移到bce.baidu.com后对AK/SK使用上的变化

bce.baidu.com这个平台在后面的描述中简称为BCE;

先看图2:
图2

从图2可以看BAE到迁移后,BAE不再属于 developer 平台,而是在BCE平台下面,与此同时BAE的扩展服务也随着BAE迁移到BCE平台下面了,但是developer下原有的一些服务如云推送等并没有迁移到BCE,同时在BAE上的应用仍然可以访问developer下其他服务提供的API或者继续使用其提供的SDK。

这时可以看到对于一个开发者来说,出现了两个平台以及两套AK/SK的管理机制。对于developer平台,AK/SK的管理没有改变,只是developer 上的AK/SK不再作用于BAE及其扩扩展服务。在BCE平台上,由于没有工程的这一概念了,所有AK/SK都是直接与用户相关的了。这时在BAE应用可以使用BCE的任意一对AK/SK来使用BAE的扩展服务(Mysql、Mongo等), 这里有个例外,就是已经下线的image扩展服务(已经申请的用户仍然可以使用), 使用的AK/SK仍需要和developer 工程下的AK/SK保持一致。而开发者如果在BCE平台上修改了AK/SK则需要修改BAE应用代码中的AK/SK才能正确使用Mysql、Mongo等扩展服务

而与BCE上不同的是,如果BAE开发者使用了developer上的云推送等服务,这时调用的developer上服务的API或者SDK的时候使用的AK/SK应该仍然应该是对应的BAE应用在迁移之前的所处的developer工程下的AK/SK,而对于BCE新用户创建的新BAE应用要使用这些developer服务的时候还需要到developer上创建相应的工程并申请相应的服务权限。这时对于这些服务调用时的使用到的AK/SK需要与developer下相应工程的AK/SK保持一致和同步

最后,很多的BAE开发者会发现,在BCE平台的下的AK/SK管理中看到的AK/SK对同其在开发中心的工程下的AK/SK是相同的, 这时因为保证迁移的平稳,在迁移过程中已将开发者中心的用户已有的AK/SK做了一份拷贝导入了BCE,但是后续开发者在developer上对SK重置,工程删除等影响AK/SK的操作不会同步到BCE。

 

BAE迁移对应用代码中的AK/SK影响总结

  1. 使用BAE扩展服务(Image 服务除外)需要用到的AK/SK是需要同BCE的上的AK/SK保持一致,包括删除,重置等操作。
  2. 使用developer上的云推送等服务时需要用到的AK/SK是developer上工程下面的AK/SK,并且需要开发者自己去保持自己应用代码中使用的AK/SK同developer中的AK/SK保持一致
此条目发表在 未分类 分类目录。将固定链接加入收藏夹。

发表评论