如何将域帐户权限传递至ASP页面

flyfranker 2011-01-25 08:44:42
公司一台服务器：Windows Server 2003 SP2，IIS 6.0，SQL 2005 SP3，域控制器
发布有一套定制开发的OA系统（ASP.NET开发），目前扩展了服务器存储空间后，准备向域用户提供一定容量的服务器存储空间，发布目录级别为：服务器盘符：\\OA系统\域共享目录\部门文件夹\个人文件夹。
需求：希望能够通过OA系统的子页面，用户在点击该页面后，出现弹出页面中，要求用户输入自己的域帐户名及口令，确认后给予访问域共享目录下级子目录的权限，访问权限与该用户所拥有的域帐户权限一致，如有可能，希望上传的文件也能够给予该域用户的所有者身份，即非调用系统administrator的权限进行写入操作。
不知道这种需求是否能够实现，如能够实现，希望能够具体告知将域帐户权限传递至ASP页面的思路或关键代码，以及关于文件夹权限配置方面的注意事项，如将某目录在IIS中发布为虚拟目录或发布为FTP目录，分配Everyone权限给该文件夹并取消子文件夹继承权限等，希望写的具体些。
分数不够可以开帖再送，非常感谢！
...全文
170 6 打赏 收藏 转发到动态 举报
AI 作业
写回复
用AI写文章
6 条回复
切换为时间正序
请发表友善的回复…
发表回复
flyfranker 2011-01-28
  • 打赏
  • 举报
 回复
感谢楼上两位，写的非常专业。
theforever 提的思路是比较专业OA软件的做法，通过程序来加密文档控制访问权限，这样文件的加密解密比较容易出问题，时间长了升级也不方便。
我只想最简单的依靠IIS的既有功能实现远程对内网文档的调取功能，哪怕只能读取文件而不可写，对我们实际需求而言也已经很实用了。
碧海情天-赵亮 2011-01-27
  • 打赏
  • 举报
 回复
楼主可能由于更熟悉硬件和服务器管理这些，所以用的思维并不是软件开发的思维。

软件开发，是用软件系统的逻辑来控制。然后软件系统的逻辑再向下通过中间件和操作系统打交道。

这个需求，说白了就是对文件的所有权（可能涉及信息保密）和空间管治（需要防范数据轰炸）。

这两方面，都完全可以通过程序进行管理，比如一对多关系+加密+文件操作与统计。

而且，由程序统一管理，比你这样一部分是纯程序，一部分又是掺杂操作系统或者IIS的额外配置，要单纯，避免了不必要的牵扯，管理维护都方便，否则，你就想象有多麻烦去吧。
flyfranker 2011-01-26
  • 打赏
  • 举报
 回复
自己顶一下，不希望通过ASP页面上传的文件是通过一个固定帐户执行写入操作，而应是每个域用户帐户所对应的权限，即对上传文件本身拥有所有权。
youngsheep 2011-01-26
  • 打赏
  • 举报
 回复
有没有域帐号其实没有多大的问题，作用都是一样
用IIS集成Windows帐号认证的方式来处理这个问题

1. 在IIS上新增一个虚拟目录，不要让它匿名访问，然后勾上Windows集成帐号认证
2. 不管ASP还是ASP.net都可以读取当前Windows用户的信息的，具体的请查看相关的资料，读到某一个帐号就通过程序新增一个目录。
3. 新增的目录一定是继承IIS认证的用户权限的，所以建立好的目录也是只有他才有权限。。


不过感觉需求太过于细节，不利于系统的扩展和网络的管理
个人感觉LZ的问题有更好的办法可以解决的，也许用非技术方面的思维来思考好些


flyfranker 2011-01-25
  • 打赏
  • 举报
 回复
补充一点，对于该功能页面的需求是不区分是否域内客户端，只要打开该页面均需要输入域帐户名及密码进行权限验证，而对于OA系统其他子功能页面无需进行域用户登陆验证。
不知道我是否发错了分区，如果版主觉得有问题，望帮忙把帖子转到ASP.NET区去。
一把编程的菜刀 2011-01-25
  • 打赏
  • 举报
 回复
这个不是和你购买虚拟机那个是一个道理么？
IIS7管理器里边 不能启动，为什么？
本人的WINDOW系统是VISTA系统，支持IIS，并且也已经安装成功，并且 1，设置应用程序池的设定也完了（ApplicationPool改为Classic.NETAppPool）， 2，权限设置也完了（Temp的权限为AuthenticatedUsers） 根据这个网址来设定的，按后在DB测试的时候有异常抱出来，不知道为什么？ サーバーはビルトイン アカウントによる指定された物理パスへのアクセスにパススルー認証を使用するように構成されています。ただし、IIS マネージャはビルトイン アカウントにアクセス権があるかどうかを検証できません。アプリケーション プール ID に物理パスへの読み取りアクセス権があることを確認してください。このサーバーがドメインに参加し、アプリケーション プール ID が NetworkService または LocalSystem である場合、\$ に物理パスへの読み取りアクセス権があることを確認してください。その後、これらの設定を再度テストしてください。
利用ASP.NET访问共享网络资源
对于许多ASP.NET开发人员而言，共享资源的访问是一个重大挑战，当开发Web表单和Web服务时就会遇到这样的挑战。微软公司的.NET拥有全新的用户授权和认证措施，大多数与安全相关的文章和书籍都用相当的篇幅解释表单认证，但是，与IIS、网络和操作系统安全相结合来理解ASP.NET安全架构是提供最佳解决方案的关健。
ASP.NET中如何防范SQL注入式攻击
ASP.NET中如何防范SQL注入式攻击 一、什么是SQL注入式攻击？ 　　所谓SQL注入式攻击，就是攻击者把SQL命令插入到Web表单的输入域或页面请求的查询字符串，欺骗服务器执行恶意的SQL命令。在某些表单中，用户输入的内容直接用来构造（或者影响）动态SQL命令，或作为存储过程的输入参数，这类表单特别容易受到SQL注入式攻击。常见的SQL注入式攻击过程类如： 　　⑴ 某个ASP.NET Web应用有一个登录页面，这个登录页面控制着用户是否有权访问应用，它要求用户输入一个名称和密码。 　　⑵ 登录页面中输入的内容将直接用来构造动态的SQL命令，或者直接用作存储过程的参数。下面是ASP.NET应用构造查询的一个例子： System.Text.StringBuilder query = new System.Text.StringBuilder( "SELECT * from Users WHERE login = '") .Append(txtLogin.Text).Append("' AND password='") .Append(txtPassword.Text).Append("'"); 　　⑶ 攻击者在用户名字和密码输入框中输入"'或'1'='1"之类的内容。 　　⑷ 用户输入的内容提交给服务器之后，服务器运行上面的ASP.NET代码构造出查询用户的SQL命令，但由于攻击者输入的内容非常特殊，所以最后得到的SQL命令变成：SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'。 　　⑸ 服务器执行查询或存储过程，将用户输入的身份信息和服务器中保存的身份信息进行对比。 　　⑹ 由于SQL命令实际上已被注入式攻击修改，已经不能真正验证用户身份，所以系统会错误地授权给攻击者。 　　如果攻击者知道应用会将表单中输入的内容直接用于验证身份的查询，他就会尝试输入某些特殊的SQL字符串篡改查询改变其原来的功能，欺骗系统授予访问权限。 　　系统环境不同，攻击者可能造成的损害也不同，这主要由应用访问数据库的安全权限决定。如果用户的帐户具有管理员或其他比较高级的权限，攻击者就可能对数据库的表执行各种他想要做的操作，包括添加、删除或更新数据，甚至可能直接删除表。 二、如何防范？ 　　好在要防止ASP.NET应用被SQL注入式攻击闯入并不是一件特别困难的事情，只要在利用表单输入的内容构造SQL命令之前，把所有输入内容过滤一番就可以了。过滤输入内容可以按多种方式进行。 　　⑴ 对于动态构造SQL查询的场合，可以使用下面的技术： 　　第一：替换单引号，即把所有单独出现的单引号改成两个单引号，防止攻击者修改SQL命令的含义。再来看前面的例子，“SELECT * from Users WHERE login = ''' or ''1''=''1' AND password = ''' or ''1''=''1'”显然会得到与“SELECT * from Users WHERE login = '' or '1'='1' AND password = '' or '1'='1'”不同的结果。 　　第二：删除用户输入内容中的所有连字符，防止攻击者构造出类如“SELECT * from Users WHERE login = 'mas' -- AND password =''”之类的查询，因为这类查询的后半部分已经被注释掉，不再有效，攻击者只要知道一个合法的用户登录名称，根本不需要知道用户的密码就可以顺利获得访问权限。 　　第三：对于用来执行查询的数据库帐户，限制其权限。用不同的用户帐户执行查询、插入、更新、删除操作。由于隔离了不同帐户可执行的操作，因而也就防止了原本用于执行SELECT命令的地方却被用于执行INSERT、UPDATE或DELETE命令。 　　⑵ 用存储过程来执行所有的查询。SQL参数的传递方式将防止攻击者利用单引号和连字符实施攻击。此外，它还使得数据库权限可以限制到只允许特定的存储过程执行，所有的用户输入必须遵从被调用的存储过程的安全上下文，这样就很难再发生注入式攻击了。 　　⑶ 限制表单或查询字符串输入的长度。如果用户的登录名字最多只有10个字符，那么不要认可表单中输入的10个以上的字符，这将大大增加攻击者在SQL命令中插入有害代码的难度。 　　⑷ 检查用户输入的合法性，确信输入的内容只包含合法的数据。数据检查应当在客户端和服务器端都执行——之所以要执行服务器端验证，是为了弥补客户端验证机制脆弱的安全性。 　　在客户端，攻击者完全有可能获得网页的源代码，修改验证合法性的脚本（或者直接删除脚本），然后将非法内容通过修改后的表单提交给服务器。因此，要保证验证操作确实已经执行，唯一的办法就是在服务器端也执行验证。你可以使用许多内建的验证对象，例如RegularExpressionValidator，它们能够自动生成验证用的客户端脚本，当然你也可以插入服务器端的方法调用。如果找不到现成的验证对象，你可以通过CustomValidator自己创建一个。 　　⑸ 将用户登录名称、密码等数据加密保存。加密用户输入的数据，然后再将它与数据库中保存的数据比较，这相当于对用户输入的数据进行了“消毒”处理，用户输入的数据不再对数据库有任何特殊的意义，从而也就防止了攻击者注入SQL命令。System.Web.Security.FormsAuthentication类有一个HashPasswordForStoringInConfigFile，非常适合于对输入数据进行消毒处理。 　　⑹ 检查提取数据的查询所返回的记录数量。如果程序只要求返回一个记录，但实际返回的记录却超过一行，那就当作出错处理。
.NET(ASP.NET)程序员 面试题 汇总(希望对你有帮助)
.NET(ASP.NET)程序员 面试题 汇总
成员资格+管理系统，第二部分：帐户设置
实施Membership +管理系统的用户帐户设置部分。
ASP

28,409

社区成员

356,971

社区内容

发帖
与我相关
我的任务
社区描述
ASP即Active Server Pages，是Microsoft公司开发的服务器端脚本环境。
社区管理员
  • ASP
  • 无·法
加入社区
  • 近7日
  • 近30日
  • 至今

加载中

查看更多榜单
社区公告
暂无公告

试试用AI创作助手写篇文章吧

+ 用AI写文章