最新评论

共2页: 1 2 下一页 
阿建 2009-12-28 13:58
能否给我解决一下,资源文件的用 代码创建 和 写入功能?
TT.Net 2009-07-08 18:05
section.Containers[0].Types[0].Configure(myContainer); section.Containers[0].Types[1].Configure(myContainer); 这一段为什么要分2个Types呢?
陈晨 2009-05-04 14:52
shop和bank的数据库是不是应该不在一个地方啊

想在存储过程中实现不大现实吧?
OnTheWay 2009-04-13 17:36
加油写啊!
期待下文!!!
Kevin Zhou 2009-03-12 16:45
@Nick Wang

谢谢~~学习了
文档还没有很详细细的去看!
Nick Wang 2009-03-12 16:42
这个说明文档里就有,如果没有名字,后注册的类型会覆盖先注册的,GetAll获得所有有名字的注册类型实例,例如:如果既注册了没名字的,又注册了有名字的,GetAll获得的集合中,不包含没名字的类型实例。
阿瑞--16hi 2009-01-09 13:15
内容少了点 呵呵
lt020202 2009-01-09 08:58
感觉if(true==..) 是C++的风格
阅读性确实比较好
Kevin Zhou 2009-01-08 11:48
--引用--------------------------------------------------
Kevin Zhou: @Bēniaǒ


~~谢谢pk
我个人觉得if(true == ...)
1.代码所表达的含义清楚
2.如果以后,我是说假如,需要更改,则if(false == ...)

当然我并不赞成2这样修改,因为这样的设计并不良好!~~
--------------------------------------------------------
我是说:如果一些地方需要if(true == ...),而另一些地方需要if(false == ...)
则需要考虑设计模式优化设计了~~
Kevin Zhou 2009-01-08 11:35
@Bēniaǒ


~~谢谢pk
我个人觉得if(true == ...)
1.代码所表达的含义清楚
2.如果以后,我是说假如,需要更改,则if(false == ...)

当然我并不赞成2这样修改,因为这样的设计并不良好!~~
Buyee 2009-01-08 10:56
.net源代码就这样写的,我觉得把true,false写出来更有利于读代码。
Bēniaǒ 2009-01-08 00:59
发现了编程之不美。
if(true == IsLeagalPartner(partnerNo))
{
//IsLeagalPartner : judge the partnerNo is leagal...
//
//进行下一步的操作
}
小提建议,何不直接
if(IsLeagalPartner(partnerNo))
{
//IsLeagalPartner : judge the partnerNo is leagal...
//
//进行下一步的操作
}

方法本来就是返回bool值,你在去与true|false判断下貌似想多了点点。
疯狂的蛋 2009-01-04 10:45
顶楼主
疯狂的蛋 2009-01-04 10:44
3Q 期待楼主再出在线购物系统分析的文章
疯狂的蛋 2009-01-04 10:38
very good ,thanks! I love you!
Kevin Zhou 2009-01-03 18:02
@clefoo
本节只谈数据加密、严谨性,防数据篡改......谢谢~~
具体的支付平台,我会再后面的部分再谈:

谢谢指教哦!!!
Kevin Zhou 2009-01-03 17:44
@丁学

谢谢~~
丁学 2009-01-03 12:17
嗯,不错不错
好像财务们都要得是非常详细的报表,楼主继续努力啊,加油!
clefoo 2009-01-02 23:50
支付系统做过,我觉得在服务端返回给客户端信息时 还应该让客户端确认后再提交回服务端,模拟TCP的三次握手原则,现在好多支付平台的API好像都没有提供,不知是否真的没必要。。 留个联系方式和LZ做进一步交流
我的MSN:clefoo@126.com
Kevin Zhou 2009-01-01 10:16
@yyc

谢谢支持,祝你新年快乐~~
Kevin Zhou 2009-01-01 10:15
@上不了岸的鱼{ttzhang}

首选祝你新年快乐

我这里实现的一个功能主要是让财务大概看出某个时间段的双方交易是否交易数相等,交易总额相等,
具体的明细,以及实际的财务明细对账,我这里并没有提供实现。

当然应该这里还有一个aspx页面去执行这个sp,
然后把最后的结果展示给财务!
Kevin Zhou 2009-01-01 10:14
@丁学

也祝你新年快乐。~~
yyc 2009-01-01 08:53
新年的第一天就看到楼主这么好的文章,非常感谢楼主,我会一如既往的关注。
上不了岸的鱼{ttzhang} 2009-01-01 00:40
大家都新年快乐哈!
不过感觉楼主的实现并不实用
丁学 2009-01-01 00:28
其实,这个对账单,一般不会用SQL跑,哈哈,实际对帐单可能复杂得多,而且还得打出来报送财务等部门,麻烦得很
祝博主新年快乐、身体健康、万事如意!
Kevin Zhou 2008-12-29 14:39
@我编程,我快乐

冒泡有个好处就是:

在shop与bank增加或者删减参数的时候,
不需要修改加密方法

如果定义的很僵化,比如: order_no + key +money +order_date
那么如果再双方再增加一个参数 partner_no,
以上的参数顺序相关的方法就得重新编码
Kevin Zhou 2008-12-29 14:37
@我编程,我快乐

冒泡排序只是对参数的一个处理,当然这个东西可以随意处理,关键在于看
bank与shop之间怎么协定,比如以下几种协定加密:

1. string validatekey = md5(order_no + money + order_date + key)

2. string validatekey = md5(order_date + money + order_no + key)

......

这是一种加密前的参数顺序协定。是shop与bank之间协议好的顺序。
丁学 2008-12-29 13:07
@Jeffrey Zhao
有人说MD5是加密么?
不过,嗯,好像追这个没什么意义,随便叫什么,知道这些做什么用怎么用不就得了?茴字有几种写法,真的很重要吗?
我编程,我快乐 2008-12-29 11:19
敢问这里的冒泡排序起什么作用?
Jeffrey Zhao 2008-12-29 11:11
MD5怎么变加密了呀……
丁学 2008-12-28 09:01
@hhhhhhhhhh
从破解角度来讲,MD5 16甚至比MD5 32要安全,因为想破解还得先补全那32位,哈哈
当然,从概率方面来讲,MD5 32的强度是远大于MD5 16的,嘿嘿
hhhhhhhhhh 2008-12-28 02:34
唯一订单 + MD532 校验 暂时很安全,没有发生漏洞;
丁学 2008-12-27 09:36
@韦恩卑鄙
3des加密的有,不过也还有好多依然坚守MD5的阵地的,呵呵
另外,这个URL放到客户端发送并没有问题,密文是在提交订单的时候计算好的,然后写回客户端,在最终确认订单时直接发送给银行/第三方
不知道你说的“误区”是什么意思?
丁学 2008-12-27 09:33
@韦恩卑鄙
嘿嘿,不好意思,我又来了,哈哈
在这里讨论,未必没有意义
更多的人是没有做过支付的,也没有用过第三方的平台,很多人可能还很费力气的去想这些办法,而楼主把这些给出了,就算是完全借鉴银行/第三方的方式,甚至就算是转发,又如何呢?一样会帮到很多人
不要说“真的做支付的人应该很清楚自己去哪里找这些”,学习成本高一点点,都是不应该的,何况很多人拿这种思路并不是做支付,也很多人本来就不会用搜索引擎 :$
所以,任何东西,只要你觉得有用,就一定会有其他人用得到,就有必要贴出来大家一起看一起讨论,反过来,如果你觉得哪个文章没有用,无视之,也不必跳出来说有无意义,这样岂不是会打击很多人?
丁学 2008-12-27 09:29
@感動常在
其实是双方按约定进行加密/摘要后比对,所以参数不同并没有什么问题,双方都是按实发参数进行规则加密/摘要的,参数不同了,自然密文/摘要也不同
感動常在 2008-12-26 23:33

string validateStr = ParamsHandle(orderNo, money, orderDate, bankNo, bankDate, 1);
if (String.Compare(validateKey, validateStr, false) == 0)
我感觉validateKey,validateStr永远都不会相等呀.


因为send,receive加密参数不同
韦恩卑鄙 2008-12-26 23:00
给大家看一个连接
http://space.taobao.com/d03a24268a26529784148cbbebbca261/show_blog-18156876.htm

taobao的支付接口文档

可以作参考。
韦恩卑鄙 2008-12-26 22:58
我觉得 在这里讨论其实没什么意义
lz 是按照bank的协议写的 bank制定协议的人其实思维很严密
就算lz不满 也没有权利修改bank制定好的公共接口

大家都没有看到相关的文档 只看到了lz的实现
其实如果随便拿到一份文档 大家自然会清楚明白的知道是怎么回事了
韦恩卑鄙 2008-12-26 22:56
@这种方法有漏洞

其实这个request应该是服务器端用组件发送
把这个url写到客户端 是业务流程不熟的人容易进入的误区了

就算是流程没做好服务器多次发送 已经确认的单子当然不会有任何变化
也就是只有重复建单问题 没有重复确认的问题









--引用--------------------------------------------------
还是有漏洞吧: @Kevin Zhou
14楼说的对 还是有漏洞
因为order No是shop发的
如果一个bank对应多个shop, bank没有办法叫他们唯一哦
--------------------------------------------------------
bank的唯一key数据是band端的交易流水号
order No只是为了商户确认自己单据用的 只需要商户端唯一 bank怎么拿到的就怎么送回去
最多写到log里面

Kevin Zhou 2008-12-26 22:55
@还是有漏洞吧

不好意思,这里我仅仅是一个举例,当然正式的接口还要有,
partner_no (商户号) -- 可识别出多个商家
还有其他的一些参数,

这里只是涉及到他的基本原理~~

当然真实的环境还有,重复支付判断,网络错误导致的“掉单”处理,IP来源判断,等等。
韦恩卑鄙 2008-12-26 22:51
@SweetBox
不是为了加密 只是用来表明 这个信息没有被别人篡改
还是有漏洞吧 2008-12-26 22:41
@Kevin Zhou
14楼说的对 还是有漏洞
因为order No是shop发的
如果一个bank对应多个shop, bank没有办法叫他们唯一哦
SweetBox 2008-12-26 22:35
我不明白MD5不可逆,用来加密订单数据,发送过能知道这是什么吗?
韦恩卑鄙 2008-12-26 21:27
最近流行的是 3des什么的 我已经很久没有见到有人用md5了
不过这一类的支付一般都不太好在信息加入中文 因为谁也说不准谁家用什么系统 谁家的某页面脚本encode有缺陷

最近一次做 Yeepay的神洲行卡支付
这才是有德商家 每个平台都有相应的类库原代码 可以直接引用工程
但是竟然有bug 我画了7个工作日和400元的神州行卡才调试找到bug
然后把去掉bug的版本发回他们技术部.......
我也是有德用户啊
Microshaoft 2008-12-26 20:58
摘要 和 加密 都没搞清楚
Kevin Zhou 2008-12-26 20:04
@这种方法有漏洞

order_no一般都是唯一,当然也可以重复,
但是 order_date + order_no 一定唯一
Kevin Zhou 2008-12-26 20:03
@这种方法有漏洞
~~
这种系统都会根据order_no判断避免重复提交的情况发生。
这种方法有漏洞 2008-12-26 19:47
对于参数 + md5 认证来说确实不易破解
但这种方法还是有漏洞,不过我说的漏洞不是hacker 可以偷用户的钱。
漏洞如下:通过URL传参过去,IE 地址栏一般会记下来, 如果用户不小点,支付完了一次(如买了一个手机),支付成功。用户不小心在IE地址中下拉找出了刚才的地址,回车,那不是又给了一次钱,支付系统会认为用户是第二次又买了。
或者是不是本人,在网吧之类的,别人点出地址来,按了回车,相当于帮别人付了一次钱。
请教这种方法按你的想法如果实现。有好的方案吗?
Kevin Zhou 2008-12-26 19:38
@Mien Ng
很早的时候,了解了一些,不是很深入! ~~
共2页: 1 2 下一页