Home  >  Article  >  Backend Development  >  javascript - 帮忙解决个设计逻辑的问题

javascript - 帮忙解决个设计逻辑的问题

WBOY
WBOYOriginal
2016-06-06 20:15:00802browse

我有一个多个服务器
其中有一个负责业务逻辑,保存所有业务数据,对外只提供私有的api接口。暂命名为API服务器;

第二台服务器,提供给微信公众号或网页端的页面,主要保存静态的html和js以及部分对接API服务器接口的php文件。暂命名为WECHAT服务器。

用户使用时,只能访问WECHAT服务器,发送给WECHAT服务器的请求,经由服务器私有的强加密api接口请求API服务器,这样外部访问权限可以靠微信的openid做判断。

但是现在有个新需求,API服务器上提供了一个新功能,其资源是针对有属性A的用户开放的,属性A与openid的关联信息保存在API服务器上的(mysql和redis都有存),但我需要在WECHAT服务器上就要向用户给出其是否有权限访问这个资源。

目前的几个方法是这样的,求大家帮忙裁断一下哪个好,或者是否有更好的方法。
1、WECHAT服务器直接去访问API服务器上的数据表。这个物理上可以实现,但是感觉不同服务跨服务器访问数据太不合逻辑。

2、在API服务器上新做一个接口API:ifOpenidHasA。这个感觉有点浪费资源,减慢系统速度。

3、在资源A的接口上做校验,请求资源A的时候判断WECHAT服务器的请求是否带参数A。这个目前貌似还好,但是以后万一有个参数ABCD对应不同资源的时候怎么搞?以及如果有超管用户拥有所有权限的话参数又怎么搞就不知道了。

补充:可能有些地方没说太清楚,补充一下:
API接口是走的加密的,目前只有WECHAT服务器发过去的加密流量能访问,是在这做的认证。现在API服务器只能对接WECHAT服务器,外部是看不到的。以后也不打算做开放的API,都是由WECHAT服务器或者以后自己的APP用,都是加密的。现在可以认为WECHAT服务器其实也是个客户端(云客户端或WEB客户端之类的)。

不过这么考虑的话以后真要做APP的话,可能方法1就不能用了。

回复内容:

我有一个多个服务器
其中有一个负责业务逻辑,保存所有业务数据,对外只提供私有的api接口。暂命名为API服务器;

第二台服务器,提供给微信公众号或网页端的页面,主要保存静态的html和js以及部分对接API服务器接口的php文件。暂命名为WECHAT服务器。

用户使用时,只能访问WECHAT服务器,发送给WECHAT服务器的请求,经由服务器私有的强加密api接口请求API服务器,这样外部访问权限可以靠微信的openid做判断。

但是现在有个新需求,API服务器上提供了一个新功能,其资源是针对有属性A的用户开放的,属性A与openid的关联信息保存在API服务器上的(mysql和redis都有存),但我需要在WECHAT服务器上就要向用户给出其是否有权限访问这个资源。

目前的几个方法是这样的,求大家帮忙裁断一下哪个好,或者是否有更好的方法。
1、WECHAT服务器直接去访问API服务器上的数据表。这个物理上可以实现,但是感觉不同服务跨服务器访问数据太不合逻辑。

2、在API服务器上新做一个接口API:ifOpenidHasA。这个感觉有点浪费资源,减慢系统速度。

3、在资源A的接口上做校验,请求资源A的时候判断WECHAT服务器的请求是否带参数A。这个目前貌似还好,但是以后万一有个参数ABCD对应不同资源的时候怎么搞?以及如果有超管用户拥有所有权限的话参数又怎么搞就不知道了。

补充:可能有些地方没说太清楚,补充一下:
API接口是走的加密的,目前只有WECHAT服务器发过去的加密流量能访问,是在这做的认证。现在API服务器只能对接WECHAT服务器,外部是看不到的。以后也不打算做开放的API,都是由WECHAT服务器或者以后自己的APP用,都是加密的。现在可以认为WECHAT服务器其实也是个客户端(云客户端或WEB客户端之类的)。

不过这么考虑的话以后真要做APP的话,可能方法1就不能用了。

我取消以前的回答了。我觉得我和你们的思路不在一个频道上,所以回答的完全驴唇不对马嘴。
我的思路还是通过授权来保证安全,但是你们的思路是通过数据的加密来保证安全,我觉得两者的性能差别是很明显的,结果现在你们发现仅仅依赖加密不能解决所有问题的时候却担心安全认证带来的性能损失...

Statement:
The content of this article is voluntarily contributed by netizens, and the copyright belongs to the original author. This site does not assume corresponding legal responsibility. If you find any content suspected of plagiarism or infringement, please contact admin@php.cn