版主就是版主，厉害

一直没弄清楚\和/的区别
好象\是物理路径
/是网络路径，
那http://有是个什么用法捏。

你是否考虑过，如上，你将本该传递用户标识的地方改成了传递用户的角色，角色是可以多个用户持有的，在今后登陆以后执行和用户密切相关的操作时，你就无法区分到底是哪一个用户在执行操作。例如，一个用户想登录以后，修改自己的基本信息。这样，你就无法在后续操作中得到用户标识，当他想这么做的时候，你不得不重新询问用户：你是谁？

铲铲版主说到点子上了，的确有这样的问题存在，

不过既然想偷工减料，就得付出代价了，我也很无奈。

有个问题请教铲铲版主：

你说用“户名登陆验证”和“角色登陆验证”在安全方面有什么区别吗？

那个更安全些？

不错，顶

我认为，本身你所提出的思路就存在概念上的不合理。
我们所说的登陆啊之类之类，归结为一个安全概念，那就是访问控制。
访问控制需要有两个必备：1、系统必须明确知道用户是谁。2、系统必须明确知道，访问这个资源的用户是否有权利。
第一个，大家很容易理解，我们经常使用“用户名”+“密码”的方式来让系统获知用户是谁。因为密码是隐私数据，我们仅认为合法用户才持有。因此，当一个用户提供了用户名和正确的密码，系统就可以认为是用系统的用户是谁。这个过程叫验证用户。

第二个，系统知道用户是谁，还必须知道用户是否有访问某个资源的权利。这个过程叫授权。一个验证、一个授权，前者是证明用户是谁，后者是决定一个资源是否允许被用户访问。

角色、组等概念并非访问控制所必须的。因为你可以在一个资源上添加“访问控制列表”，在该表中明确指定每一个用户是否有权访问它的记录，当一个用户要访问时，通过查表以决定是否允许。但这样会造成“访问控制列表”过于庞大，当用户成千上万时，它的伸缩性、性能非常低下。并且，为每个资源维护用户的访问表，其维护量基本上等于用户数和资源数的乘积，相当庞大。
于是，思考是否引入一个中间环节，将用户和资源对应关系进行缓冲。这就是角色、或者组。随你怎么说，只要在一个项目中，这些概念的含义相同就行。我们对资源的授权并不针对用户，而是针对角色或者组。
我认为，用角色的概念更贴近现实生活。首先、一个人有可能担当多种角色：例如，一个老师，对于学生，他是老师的角色，对于学校，他是工作者的角色，对于家庭，他是父亲/母亲的角色，对于银行，他是业务办理者的角色。其次，一个角色可能有很多人在扮演，全世界不止一个教师，银行也不乏仅他一个业务办理者。
因此角色和用户是N对N的关系。
当然，用“组”这个概念同样可以，随你怎么说，这取决于你的设计。

所以，对于你的设计而言，违背了最初设计原则。如楼主所说偷工减料吧，这样付出的代价就是违背设计原则，导致信息不全。在我的基于角色的安全访问中，任何元素都是必须的，没有冗余。


高阶技巧：
美国国家标准协会倡导了RBAC（基于角色的访问控制Role-based Access Control）。他还指定了RBAC的三种标准，分别是RBAC0、RBAC1、RBAC2。其中RBAC0是最基本的角色访问控制标准。如同我所有帖子一样，他们都是RBAC0的，用户和角色这两个元素都是没有层次结构的（属于平面数据）。更复杂RBAC系统，用户和角色的组织形式是树状结构的，并且，对于访问控制元来说，还可区分“允许”“拒绝”“未指定”，对控制策略来说，可以分为“拒绝优先法”等等，对于用户和角色呈现的树状结构，还存在追溯权限和继承关系，权限怎么追溯、怎么继承、怎么叠加等，都是设计访问控制需要考虑的问题，还有就是这些追溯、继承算法是否满足性能要求。

谢谢，学到点东西

我以前也和楼主差不多了做法,真的是存在很多不合理性,因为我只有一个管理员,很好解决,
看了可爱的铲铲发的文章以后(其实以前也搞过.其实没有搞懂),感觉太大了,
铲铲,我在等你QQ,因为我还有一些东西想问你,我QQ是:84420676

谢谢CHANCHAN版主的解释

先顶再说。。。。。。。。。。。