圈主去杭州D2论坛晃一圈，周六晚上才回上海
 |
netfork
2009-12-19
icewubin 写道 netfork 写道 楼主，明天见！
楼主天天见，青年旅社的输入法不好使，人已在杭州。 哈哈，抢了一本书 |
 |
icewubin
2009-12-19
netfork 写道 哈哈，抢了一本书
您是哪一位，现场抽中N个人，没人愿意要那个T恤，我们公司三个前端都抽中奖品，本人运气不佳。 |
|
netfork
2009-12-20
icewubin 写道 netfork 写道 哈哈，抢了一本书
您是哪一位，现场抽中N个人，没人愿意要那个T恤，我们公司三个前端都抽中奖品，本人运气不佳。 偶的运气也暴差，是自己抢了个问题问了问才抢了本书。 我问的是，为什么淘宝要使用hidden的token，而不使用页面级cookie存放token，这样就可以通过一个配置文件来把所有需要token的页面管起来了，否则还得手工往每个需要token的页面中增加三个hidden变量，非常繁琐。 但是回答我不太满意。后来，口碑的大牛在讲解中也回答了这个问题，但是还是感觉回答的很牵强，或许是本人层次太低，还理解不了其中的原由。 |
|
icewubin
2009-12-20
netfork 写道 偶的运气也暴差，是自己抢了个问题问了问才抢了本书。
我问的是，为什么淘宝要使用hidden的token，而不使用页面级cookie存放token，这样就可以通过一个配置文件来把所有需要token的页面管起来了，否则还得手工往每个需要token的页面中增加三个hidden变量，非常繁琐。 但是回答我不太满意。后来，口碑的大牛在讲解中也回答了这个问题，但是还是感觉回答的很牵强，或许是本人层次太低，还理解不了其中的原由。 大牛们回答的很正确，没有任何问题。 1.为了减少每次请求的带宽，cookie中一般是尽可能减少数据的存储的。 2.一点也不繁琐，你看到的是生成后的html，原始标签要简单得多。token的概念很早很早就有了，因为我是搞后端java的，所以看到之后很熟悉。 你还有什么疑惑尽管提，我应该能说清楚这个问题的。 现场有两个人讲的不太好，一个是讲模板语言的，一个是讲SilverLight的，由于现场的观众可能后端和RIA经验不多，我个人感觉这两方面讲的是比较糟糕的。 |
|
netfork
2009-12-20
呵呵，我们来探讨一下也好。
1、放在hidden里不是照样影响带宽吗？Cookie中的数据可以每次清空嘛，只有在需要的时候才注入。 2、如果使用了这个额外的token，那么每个新建的页面都要额外加入这个与业务毫不相关的标签，原来的页面也需要修改增加这个标签。如果我们使用一个Filter，配置一个象struts-config.xml一样的设定文件，在其中配置需要增加token处理的页面，自动在Filter里将token注入页面级cookie里该多好？这个提高安全的token才是真正意义上的金钟罩，不需要页面做任何额外的处理。就象AOP想实现的一样。 jindw想传达的一是个很牛的东西，可惜他的ppt准备的不够好，讲演时也没有充分展开，以致于很多人根本不知道他讲的是什么。SilverLight的讲演人也并没有讲到实处，也完全没有聚焦。 |
|
icewubin
2009-12-20
netfork 写道 呵呵，我们来探讨一下也好。
1、放在hidden里不是照样影响带宽吗？Cookie中的数据可以每次清空嘛，只有在需要的时候才注入。 2、如果使用了这个额外的token，那么每个新建的页面都要额外加入这个与业务毫不相关的标签，原来的页面也需要修改增加这个标签。如果我们使用一个Filter，配置一个象struts-config.xml一样的设定文件，在其中配置需要增加token处理的页面，自动在Filter里将token注入页面级cookie里该多好？这个提高安全的token才是真正意义上的金钟罩，不需要页面做任何额外的处理。就象AOP想实现的一样。 jindw想传达的一是个很牛的东西，可惜他的ppt准备的不够好，讲演时也没有充分展开，以致于很多人根本不知道他讲的是什么。SilverLight的讲演人也并没有讲到实处，也完全没有聚焦。 1.那位大牛是以为你要在每个页面里的cookie中都放数据，才会这么说的。 2.那位大牛后来会场上说过，需要的页面再加token，并不是每个页面都加。 3.其实你是想和大牛讨论token的具体加载机制，但因为时间仓促你们互相需求都还没有说清楚。就我的理解来说，放cookie中是很不灵活的，例如一个页面上可能有多个form表单，每个表单都有自己的token，如果放在cookie中自然就更麻烦，会传递多余的token。如果原始页面本来就是牵涉到多功能模块，页面生成的token服务器还不一样（中间由portal合在一起），这在大型网站是很正常的，此时服务端是不太适合用某种统一的filter来处理的，服务器都有可能是分布式的。 当然以上是我的假设。在一定的前提条件，你一定要利用cookie放token当然也是可以的，只是我和那个大牛认为不合适而已。他说的很多模板的好处并不是只有模板特有的，我们公司在实践前端的软件工程学的过程中也有很多处理方式，JS和模板语言的分工我们也讨论过很多次了，其中细节牵涉到不少东西，如果想听我可以说的很详细。 还有种情况就是，如果某个form还不是仅仅是页面生成，如果是前端代码JS异步请求动态生成的form表单数据，此时用cookie存放也是比较麻烦的。 A）我不觉得jindw传达的东西有多牛，我用模板很多年了，很多思想N年前就有了，如果说类似的东西，GWT不也是现成的么？最主要的是，我认为既然承认了JS的地位，就应该更多的从JS考虑来解决问题，而不是更多的依赖后台的模板。 B）我从一开始就质疑SliverLight的一些特性，更为搞笑的是，主讲人自己最后承认SliverLight的http长连接不稳定，而要借助于flash，我们公司的flash工程师已经笑翻掉了。 |
|
netfork
2009-12-20
很好。
关于上面的3，我认为是不可能存在同一页面多form使用不同token的情况的。 我认为实际上淘宝采用的应用于安全的token方式，是针对每一位登录用户，在db中设置了对应的token项，每一位用户只有一个对应的token组合，只有用户这次提交的token值与db中的token以某种方式对应起来时，才认为是正确安全的请求，如果不一致就认为是非法请求。 所以，不可能出现同一个页面多个token的情况，因为这种情况下，可能提交到server的token值会有多样性，而db中对应的值只有一个，这样一来，就无法通过token来确保安全了。 说到js异步请求，那更是filter+cookie的拿手好戏，比起hidden的方式，要简单不少。因为如果是通过hidden，那么js拿到了数据(xml or json)后，还需要再解析这些token项。而通过cookie，就根本不用理会token的field项了。 另外，不知道我记没记错，明城似乎提到了关于专用的token服务器的事，实际上，就是filter的机制，在数据到达真正的业务处理之前，在外面套了个filter服务器，进行token值的判断。所以，很明显完全可以用统一的filter来处理token的。Server侧使用db存储每位用户的token值，所以，分布式也好，不分布也好，统一的filter处理完全没问题。 上文提到的db，可以换成类memcached的缓存db。 我相信jindw不会拿着n多年的东西来忽悠大家吧，只是那大哥讲演水平实在不怎么样，真没讲明白。呵呵，当然只是猜测，因为这个真没明白。 关于“JS和模板语言的分工”，愿意洗耳恭听楼主的分享。 谢谢指教。 |
|
icewubin
2009-12-20
netfork 写道 很好。
关于上面的3，我认为是不可能存在同一页面多form使用不同token的情况的。 我认为实际上淘宝采用的应用于安全的token方式，是针对每一位登录用户，在db中设置了对应的token项，每一位用户只有一个对应的token组合，只有用户这次提交的token值与db中的token以某种方式对应起来时，才认为是正确安全的请求，如果不一致就认为是非法请求。 所以，不可能出现同一个页面多个token的情况，因为这种情况下，可能提交到server的token值会有多样性，而db中对应的值只有一个，这样一来，就无法通过token来确保安全了。 说到js异步请求，那更是filter+cookie的拿手好戏，比起hidden的方式，要简单不少。因为如果是通过hidden，那么js拿到了数据(xml or json)后，还需要再解析这些token项。而通过cookie，就根本不用理会token的field项了。 另外，不知道我记没记错，明城似乎提到了关于专用的token服务器的事，实际上，就是filter的机制，在数据到达真正的业务处理之前，在外面套了个filter服务器，进行token值的判断。所以，很明显完全可以用统一的filter来处理token的。Server侧使用db存储每位用户的token值，所以，分布式也好，不分布也好，统一的filter处理完全没问题。 上文提到的db，可以换成类memcached的缓存db。 1.token服务器未必要关心到某个用户，因为不能假设网站所有功能都是针对注册用户的。 2.“每一位用户只有一个对应的token组合”这个假设也是不合理的，一个注册或者匿名用户页面可以有多个token，只要设置token的失效时间和次数限制（这里讨论的场景就是1次），就可以让一个页面有多个有效的token。 而且“每一位用户只有一个对应的token组合”这种算法也有不完备的场景，例如某页面显示了一个token，后台记录了这个唯一的token，但是用户新开了一个商品页面，是不是会在新页面中产生新的token，如果让老的token失效，是否老页面就不能再有效操作了？这样的策略是不合理的。 3.一个页面一个token也是不合理的，我之前说过一种分布式的结构，例如，某一个商品页面上的“收藏”功能和“购买”功能，提交的就是不同的服务器，假设收藏功能不需要token信息，而购买功能需要token验证信息，这样的灵活度还是很常见的吧。 4.从安全角度和业务功能角度，我个人认为注入token、图形验证码这些信息就是应该包含在一个请求的语义中的，而不应该有filter来处理，这对业务处理是不合适的，因为token不合法或者验证码输入错误，前端都是要有相应的提示的，既然有相应的复杂提示，虽然是一些提示信息，一样是这个模块的业务逻辑的一部分。（个人观点） |
|
icewubin
2009-12-20
netfork 写道 关于“JS和模板语言的分工”，愿意洗耳恭听楼主的分享。
谢谢指教。 首先要有质疑的精神，并不是故意挑刺，而是通过质疑和分析某种方法的缺点，反过来看清楚这个方法的优点和可行性。 1.首先是要考虑网站的数据显示方式分哪几种，一类是第一次页面渲染时显示，另一类是Ajax异步加载的。 如果一个网站有相当多的数据是要通过第二种方式的话，过多的依赖于模板语言是不合适的，因为模板语言只适合第一种数据显示方式。 2.前端在开发调试时，往往有自己的一套开发环境，虽然和后台页面显示不能完全解耦，但是过多依赖模板语言，调试起来往往是不方便的，需要后台开发人员协助发布新的模板。当然jindw说他那套东西也有调试工具，但是前端一般都是基于FF来调试的，两套工具还要组合，貌似有难度吧，毕竟一个是服务端的，一个是客户端的。 3.我没理解错的话，jindw应该说过可以利用模板生成CSS和JS吧，代码生成我一般都是反对的，我总认为有更好的方法能替代代码生成，代码生成到底好坏不展开了，纯粹个人观点而已，这个话题一展开就没底了。我认为既然有专职的前端工程师，CSS和JS就应该由前端统一规划，而不要由后端来代劳。后端应该只提供数据，而不应该过多的涉足前端UI逻辑。当然我说的后端是指运行在服务器上的代码。 |
|
netfork
2009-12-21
虽然不能苟同，但是楼主是值得尊重和尊敬的，谢谢了！
|
