这段代码实现的是一个典型的ASP用户登录验证流程，逻辑清晰，结构也中规中矩。不过在实际项目中，有几个关键点值得多留个心眼，尤其是安全性和健壮性方面。
先看代码的主干逻辑：它首先检查Session中是否已存在用户标识（cust_id），如果有，就直接跳转到主页（dashbrd.asp），避免重复登录。这是常规的会话管理思路，没什么问题。
当用户提交登录表单（uid和pwd）后，代码会先检查这两个字段是否为空。如果为空，就将bLogin置为True，但这里有个细节——它没有设置bError标志，也就是说，空字段提交不会触发错误提示，可能会让用户感到困惑。从用户体验角度，更好的做法是明确告知用户“请输入用户名和密码”。
验证的核心部分是通过SQL查询从customer表中匹配用户名和密码：
“select * from customer WHERE cust_id=′” & request(“uid”) & “′ and ′cust_pwd=′” & request(“pwd”) & “′”
这里有一个非常关键的安全隐患：直接拼接用户输入构造SQL语句，存在SQL注入风险。只要在用户名或密码框中输入类似“' OR '1'='1”的内容，就能绕过验证。在正式系统中，这绝对是必须修复的漏洞，建议改用参数化查询或存储过程。
查询成功后，代码会将用户的cust_id、cust_pwd和power（权限）存入Session变量。这个设计意图很明确：在后续页面中直接读取这些Session值来判断用户身份和权限。不过，不建议在Session中存储明文密码，一来是安全风险，二来也没必要——只要在登录时验证一次密码即可，后续只需要确认用户身份。
代码中还包含一段被注释掉的SQL更新语句，用于记录用户最后登录时间。这其实是个不错的做法，但被注释掉了。如果系统有审计或用户行为分析需求，建议保留并启用这个功能。
最后，验证通过后跳转到dashbrd.asp（主页），验证失败则将bError置为True，同时bLogin也置为True，然后在同一页面显示错误提示。这种“自提交”模式（表单action指向本页）确实能避免跳转带来的额外请求，但对于复杂的登录逻辑，可以考虑将验证逻辑和展示逻辑分离，让代码更清晰易维护。
整体来看，这段代码完成了登录验证的核心功能，但在安全性和用户体验方面还有优化空间。如果是在生产环境中使用，建议至少加上防SQL注入处理、密码加密存储（如MD5或更安全的哈希算法），以及更友好的错误提示机制。
图片占位符：
[图片：登录流程图（略）]
