Best Practice

胖子

老兵提到的问题，是不是有一个前提：各层校验的对象是一致的？既从逻辑上来说，数据在各层次间流动时，不发生改变。
& L$ P' p3 _: q* v7 Y  G1 {) }1 ?
如果是这样的话，倒确实不用每层都校验。而应把关注点放在数据传递安全上，也就是防篡改。

如果数据流动过程中会变动，那我同意空气精灵的观点。

四处张望

老兵帅客 发表于 2011-9-28 17:13
esb那个全是自己搞的，而且预先知道就放在自己的内部机器上。

理解不能，除非ssl这类都是缺省实现，懒得去掉，否则多个ssl多讨厌。

老兵帅客

胖子 发表于 2011-9-28 04:33
老兵提到的问题，是不是有一个前提：各层校验的对象是一致的？既从逻辑上来说，数据在各层次间流动时，不发 ...

8 S! u/ w& I- v5 s$ }, x0 s各层的校验数据是一样的，就是从表示层那里得到的同一个java bean，内容不变。同时因为这是个在同一个java ee server下面运行的web app，不存在数据在中间遭到篡改的可能。

老兵帅客

四处张望 发表于 2011-9-28 04:41
% z, o2 S7 Q: B; t$ x7 ~理解不能，除非ssl这类都是缺省实现，懒得去掉，否则多个ssl多讨厌。

不是的，ssl设置都是要单独做的，而且还是双向ssl，也就是双方互相验证再建立ssl。

四处张望

老兵帅客 发表于 2011-9-28 19:02
5 ^/ K( v* A* K( C; Y1 M. b不是的，ssl设置都是要单独做的，而且还是双向ssl，也就是双方互相验证再建立ssl。 ...

, w1 S) a5 ?; {3 ]; u这个不就是等于保险箱里面再加吧锁吗，追求小数点后面的几个0呢？

老兵帅客

四处张望 发表于 2011-9-28 20:52
7 z' c) N; p1 d$ w' g" c这个不就是等于保险箱里面再加吧锁吗，追求小数点后面的几个0呢？

, A' N( F* e- F7 E0 N6 Q没办法，安全这个领域太敏感了，多些安全总比少些强

四处张望

老兵帅客 发表于 2011-9-29 09:59
' p) n0 l- N, Q( L4 y9 F5 y" x- ~没办法，安全这个领域太敏感了，多些安全总比少些强

不过计算性能开始不值钱了，多点安全拖累性能无所谓，不要多人工就好。

猫元帅

专业词汇一个不懂，但是意思大概明白了。

& ^4 x3 B3 l2 I就是帅克同志认为在1－2－3递进的情况下，2和3不会发生超出1的BUG。所以只要1做得完善，检测1就足够了，用同样的方法检测2和3是一种浪费。不能为了检测而人为改变1的设置，因为1－2－3是递进的关系。

简单说就是不能为了检测而检测。

老兵帅客

猫元帅 发表于 2011-9-29 19:47
专业词汇一个不懂，但是意思大概明白了。
) O6 {6 X' y  P! s0 E4 s
: D( E0 h- w# P# u9 h就是帅克同志认为在1－2－3递进的情况下，2和3不会发生超出1的BU ...

对，不应该做多余的事情

ImaNut

小绿爷 发表于 2011-9-27 22:17
3 T$ n1 q4 e2 P隔行如隔山，对我而言基本看不懂

就好比一座办公楼，大门口一把门的，电梯一守卫，你办公室门口又是一位，连厕所那儿也摆一位，进出都查ID。理由是有人能钻窗户进来。

老兵帅客

ImaNut 发表于 2011-9-30 08:46
  L. D9 E- Z! F就好比一座办公楼，大门口一把门的，电梯一守卫，你办公室门口又是一位，连厕所那儿也摆一位，进出都查ID ...

问题是这大楼根本没窗户也要这么干，那就是多此一举了。

牌牌

作为一个前C++程序员表示理解起来压力不大。
6 C' [* v- K8 N* t现在的软件工程为了提高代码的重用性和可靠性，要求各个代码模块对所有的输入都进行合法性检查以保证业务逻辑的正确运行，所以CPU内存增长的再快，也不扛不住做总是在做无用功的软件啊。

老兵帅客

牌牌 发表于 2011-10-1 04:01
作为一个前C++程序员表示理解起来压力不大。
7 W9 _+ i2 Y) O) z1 h现在的软件工程为了提高代码的重用性和可靠性，要求各个代码模 ...

的确如此。

ekid

怎么软件也像协议分层吗？

sky100

看你怎么看这个问题了。现代的软件工程都是多人甚至多团队合作型，万一其中的一个模块外包到印度去，那边的开发人员乱写一气，污染了数据，然后下一级别的模块没有做数据效验怎么办？现实世界中总是有各种意外的。当时觉得没必要的事情，过几年之后可能会觉得是重要的。

# W' B* a7 [1 y( z8 i. D从架构设计的角度来说，这样做对于扩展性很有好处。比如，现在你只用一台机器跑所有的web service.可是明天用户忽然增多，一台机器撑不住了，必须多台机器集群作战。这时这样做的好处就出来了，软件层面基本上不用作修改就可以分布到多台机器上用。如果象你想的那样内部通讯不需要安全验证，那么扩展起来还需要重新作安全验证，这样又会从另一个方面来增加工作量。是机器便宜还是开发人员的工资便宜呢？Really depends.
/ U$ }3 z( f* R  ^7 C2 ^6 t
" n- V" c/ f6 I- }7 ^* k很多时候设计决策本身就是一个trade off.

4 a7 b5 y9 Q3 w" J) d% H
" o2 t! J- Q. U* n! q4 ^

老兵帅客

ekid 发表于 2011-10-1 08:10
怎么软件也像协议分层吗？

是啊，一直都是这样做的

老兵帅客

sky100 发表于 2011-10-1 10:55
6 n& i$ j0 t/ K+ B+ \. p看你怎么看这个问题了。现代的软件工程都是多人甚至多团队合作型，万一其中的一个模块外包到印度去，那边的 ...

0 F4 R  a, R0 W第一。测试是干什么的？
! a& Z( P4 T; s. J# Y, Q, Y
# [. ]1 x. P! k" K% H; o第二。如果那堆web service根本不可能被deploy到外网呢？

; R9 e' j3 Z* ~我明白你的意思，但是这个trade off理论上很合理，现实中则根本没有得益的时候，而成本却肯定在那里。

一瞬无尽

这种每层都验证数据的做法我觉得没错
% t& ^9 a* Q# \4 ?测试的做法我觉得似乎可以改进：通过修改下层的实际代码进行测试，这似乎过分了些
8 b$ J' @  x8 v/ \* Y我不了解实际情况，觉得似乎可以干脆另写测试代码，模拟下层专门发送错误数据给上层，不然每次测试都修改生产代码，太麻烦太浪费了

我如果是上层写代码的，宁愿自己写这个测试也说不定，当然能安排给下层是最好了

老兵帅客

一瞬无尽 发表于 2011-10-2 04:53
这种每层都验证数据的做法我觉得没错
2 {) }# f& Z( D测试的做法我觉得似乎可以改进：通过修改下层的实际代码进行测试，这 ...

Good, you do that

老兵帅客

一瞬无尽 发表于 2011-10-2 04:53
这种每层都验证数据的做法我觉得没错
测试的做法我觉得似乎可以改进：通过修改下层的实际代码进行测试，这 ...

3 o8 W4 d4 L  }% b0 e: j% I其实说起来，这个就看怎么做了，做得好的话是可以灵活配置的，也就是需要的话enable检测代码，否则disable掉就是。具体说来就是利用framework的能力，例如struts2的interceptor，可以做出几乎不带来额外开销而非常实用的检测程序来。