断断续续的烟雨给江南披上了一件白色的纱衣，这件飘若浮云，清净如水的嫁纱，迷蒙了往昔，模糊了过去。我开始在其中憧憬，永远的置身于这种氛围中，让世俗的纠缠远离。
比如： 验证码存储在页面代码或Cookies里，暴露给客户端；
通过Session存储的验证码，虽然解决了安全问题，但一个用户只使用一个变量存储验证码，假如用户同时打开一个以上的页面，分别提交的话，就无法正常使用了；
验证码不会过期，这会留下隐患，使暴力破解变得可行(当然也可以通过刷新间隔、提交间隔、黑名单等手段加以控制)；
此外还有伴随着提交产生的另一个问题——重复提交。
为解决上述问题，我曾走过不少弯路，后来总结出了一个方案可以很好的解决这些问题，本文将结合ADO.NET Entity Framework技术来介绍此方案：
这方案的核心就是通过数据库统一存储所有请求页面所对应的验证码及其相关信息(这也可以通过Session或别的什么实现，但个人感觉数据库更为优秀)。
首先来建立一个这样的SQL Server数据表，表名设为“提交验证”：
“ID”字段存储的是该验证信息的唯一ID，用于查询，并且我们还会将此值传给客户端用于回发时再度获取对应的信息，采用GUID格式保证了唯一性和复杂性，客户端几乎没有伪造的可能；
“会话ID”字段即用于存储SessionID，以确保验证信息与用户会话相对应，如果你不在意客户端是否会被劫持的话，也可以忽略这个字段。
“验证码”字段即存储验证码原文，用于检验用户输入，此外，验证图片生成函数也会通过ID获取此数据以生成对应的验证图片。
“是否已提交”字段标识此验证信息是否已使用过，如果不需要给用户明确的错误提示的话，可以在提交后直接删除所使用的验证信息，而不使用这个字段。
“过期时间”字段的数据将会在清理超时信息时使用到。
数据库建好后，就可以建立ADO.NET Entity Framework数据模型(EDM)了：
此模型从现有数据库直接生成即可，不需要做什么额外改动。未完待续，此篇中介绍了数据结构和思路，在下篇中将介绍代码实现以及使用方法。
以上就是较为全面的Asp.net提交验证方案分析 (上)。云随风走，无转回。爱情却不一样，只要心中长存那片温暖，或许某一天，你会在曾经失落的地点，再找回来。更多关于较为全面的Asp.net提交验证方案分析 (上)请关注haodaima.com其它相关文章！