|
精华帖 (4) :: 良好帖 (0) :: 新手帖 (0) :: 隐藏帖 (0)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2012-04-29
kelloKitty 写道 stamen 写道 kelloKitty 写道 lz的开源的精神值得大家学习，我看到淘宝开源平台api有一个系统参数session，l你能描述一下ROP的会话验证机制吗？还有就是ROP支持服务端超时重试机制吗？谢谢。
Rop中有一个sessionId的参数，和TOP的session是一样的。开发者通过实现SessionChecher 进行会话的安全管理。如果有某些方法不需要session，则可以标注：@ApiMethod(needInSession=false)。 超时重试机制我要了解下。 1）SessionChecker：会话检查组件，大多数服务方法都必须在会话环境下进行，使用该组件判断请求会话的合法性 你好，lz，关于SessionChecker组件我还是没能明白，能否详细描述一下SessionChecker将要实现什么样的验证吗？Rop的系统参数是有一个session的参数，假如客户端传参session=test。服务端SessionChecker将如何验证安全处理？ 首先应用服务必须开发一个会话获取的服务:即通过用户密码等凭据获取一个sessionId，服务端维护这个sessionId,而客户端通过获取后，也必须在本地持有这个sessionId，其后的所有服务都附带上这个sessionId,服务端据此判断会话的合法性，判断会话合法性就由SessionChecker来做。 |
| 返回顶楼 | |
|
发表时间：2012-04-29
stamen 写道 kelloKitty 写道 stamen 写道 kelloKitty 写道 lz的开源的精神值得大家学习，我看到淘宝开源平台api有一个系统参数session，l你能描述一下ROP的会话验证机制吗？还有就是ROP支持服务端超时重试机制吗？谢谢。
Rop中有一个sessionId的参数，和TOP的session是一样的。开发者通过实现SessionChecher 进行会话的安全管理。如果有某些方法不需要session，则可以标注：@ApiMethod(needInSession=false)。 超时重试机制我要了解下。 1）SessionChecker：会话检查组件，大多数服务方法都必须在会话环境下进行，使用该组件判断请求会话的合法性 你好，lz，关于SessionChecker组件我还是没能明白，能否详细描述一下SessionChecker将要实现什么样的验证吗？Rop的系统参数是有一个session的参数，假如客户端传参session=test。服务端SessionChecker将如何验证安全处理？ 首先应用服务必须开发一个会话获取的服务:即通过用户密码等凭据获取一个sessionId，服务端维护这个sessionId,而客户端通过获取后，也必须在本地持有这个sessionId，其后的所有服务都附带上这个sessionId,服务端据此判断会话的合法性，判断会话合法性就由SessionChecker来做。 这个感觉和应用密钥管理组件的实现原理差不多呢，客户端传参sessionid到服务端，服务端拿到这个sessionid参数值和服务端维护的sessionid做比较，如果相同则合法，是这样吗？但是服务端维护的sessionid这个值是什么呢？ 如果是应用密钥管理组件，他有自己的appKey/密钥对，类似以配置文件方式保存的，难道SessionChecker维护的session也是以配置文件方式进行管理的吗？ |
| 返回顶楼 | |
|
发表时间：2012-04-30
支持国人原创开源
|
| 返回顶楼 | |
|
发表时间：2012-05-02
kelloKitty 写道 stamen 写道 kelloKitty 写道 stamen 写道 kelloKitty 写道 lz的开源的精神值得大家学习，我看到淘宝开源平台api有一个系统参数session，l你能描述一下ROP的会话验证机制吗？还有就是ROP支持服务端超时重试机制吗？谢谢。
Rop中有一个sessionId的参数，和TOP的session是一样的。开发者通过实现SessionChecher 进行会话的安全管理。如果有某些方法不需要session，则可以标注：@ApiMethod(needInSession=false)。 超时重试机制我要了解下。 1）SessionChecker：会话检查组件，大多数服务方法都必须在会话环境下进行，使用该组件判断请求会话的合法性 你好，lz，关于SessionChecker组件我还是没能明白，能否详细描述一下SessionChecker将要实现什么样的验证吗？Rop的系统参数是有一个session的参数，假如客户端传参session=test。服务端SessionChecker将如何验证安全处理？ 首先应用服务必须开发一个会话获取的服务:即通过用户密码等凭据获取一个sessionId，服务端维护这个sessionId,而客户端通过获取后，也必须在本地持有这个sessionId，其后的所有服务都附带上这个sessionId,服务端据此判断会话的合法性，判断会话合法性就由SessionChecker来做。 这个感觉和应用密钥管理组件的实现原理差不多呢，客户端传参sessionid到服务端，服务端拿到这个sessionid参数值和服务端维护的sessionid做比较，如果相同则合法，是这样吗？但是服务端维护的sessionid这个值是什么呢？ 如果是应用密钥管理组件，他有自己的appKey/密钥对，类似以配置文件方式保存的，难道SessionChecker维护的session也是以配置文件方式进行管理的吗？ 一般互联网的应用不会使用WebServer的HttpSession来管理会话的，一般要自己做会话管理，通过数据库或者缓存服务器等管理用户的会话。说白了也就是一个Map,sessionId代表用户的会话ID,而值存放着会话的上下文信息。 关于会话的管理的具体实现，Rop没有提供（因为这个应用相关性很大）。只是提供一个sessionId，你产生会话时要返回一个sessionId给客户端，客户端附带这个sessionId时，你即可以检查会话。 |
| 返回顶楼 | |
|
发表时间：2012-05-27
这周末抽空看了LZ写的代码, 提两个建议:
1.请求服务缺少了json->object的转换器, 按照作者的代码, 实现了json->object, 根据消息格式进行适配转换. 2.LZ大量采用了spring mvc的代码, 后面感觉和spring mvc 的控制器没多少区别, 只是增加了会话 / 签名的安全性 / 消息错误体制. 最后我问了我几个同事, 还是我们没学到位, 我们一致认为跟spring mvc没多少区别. |
| 返回顶楼 | |
|
发表时间：2012-05-28
小树鹿鸣 写道 这周末抽空看了LZ写的代码, 提两个建议:
1.请求服务缺少了json->object的转换器, 按照作者的代码, 实现了json->object, 根据消息格式进行适配转换. 2.LZ大量采用了spring mvc的代码, 后面感觉和spring mvc 的控制器没多少区别, 只是增加了会话 / 签名的安全性 / 消息错误体制. 最后我问了我几个同事, 还是我们没学到位, 我们一致认为跟spring mvc没多少区别. 1.json -> object 的我确实还没有实现，今天就给他添加下 这个非常容易； 2.是的，在实现时是参考了Spring MVC的框架和TOP框架。和Spring MVC不是一个类型的东西，Rop的应用层的Web Service框架，实现上和Spring MVC类似，功能用途大不一样。 |
| 返回顶楼 | |
