前几天的发现的那个关于将一个假设好的网站copy到另外的一个地方后不能重要找到原因了,那就是关于membership中的applicationname的attribution的设置。同时也发现了在解决问题中的一些问题,比如为了解决这个问题而将iis和NTFS文件中的用户权限设置搞的一塌糊涂,呵呵。现在关于以上解决的问题来总结一下,并且对于解决方法 探讨一下:
学习了关于iis和NTFS文件系统的权限设置,具体设置可以看这里:http://blog.csdn.net/spirit_only/archive/2006/09/09/1198432.aspxapplicationname属性的设置,参考了范肖维的一篇翻译,希望碰到同样问题的朋友能够自习研究啊!在配置使用Membership或其他的Providers的ASP.NET2.0时一定要设置applicationName属性原文:Always set the "applicationName" property when configuring ASP.NET 2.0 Membership and other Providers 作者:Scott Guthrie翻译:范维肖注释:对于个别名词保留英文描述或翻译参考。
场景:在本地开发一个asp.net2.0的应用程序时使用了Membership、Roles或Profile特性。你创建了一些新用户,一切都没有问题。
然后把这个程序copy到远程服务器(remote server)上(或者只是移动到你本地服务器上的其他目录)然后运行。由于某种原因,虽然我们能够连接到membership数据库,但是当登陆的时候就会出现错误了,它并不抛出连接错误(connection error),而是提示你像类似的错误:“尝试登陆失败,请重试”(Login attempt unsuccessful, please try again)
原因:这种经常出现的错误的原因是因为membership(或者是roles、profile) provider已经被加入到了程序的web.config里了。但是applicationName属性(attribute)并没有被指定(假设下面的代码的粗体部分布存在地话)
<membership> <providers> <clear/> <add name="AspNetSqlMembershipProvider" type ="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName ="LocalSqlServer" enablePasswordRetrieval ="false" enablePasswordReset ="true" requiresQuestionAndAnswer ="true" requiresUniqueEmail ="false" passwordFormat ="Hashed" maxInvalidPasswordAttempts ="5" minRequiredPasswordLength ="7" minRequiredNonalphanumericCharacters ="1" passwordAttemptWindow ="10" passwordStrengthRegularExpression ="" applicationName ="/" </providers> </membership> />如果applicationName属性没有被配置的话,当往程序的数据库里添加数据的时候,asp.net会使用程序在web服务器里的虚拟目录路径(vroot Path)自动的计算applicationName的值。我们打开aspnetdb数据库,看aspnet_Applications表,就能了解这一行为:
这个表里为每个applicationName存储了一个具有唯一值(unique)的ApplicationID。因为在我们的程序里注册一个用户的时候并没有指定一个applicationName属性,所以它自动的被设置(计算)为/website8(早期建立项目时的名字)
然后,使用membership API创建的用户会与ApplicationID相关联,这样可以找到applicationName(and in turn the applicationName)。【这样做的目的可以让我们的多个应用程序和站点使用同一个数据库】。打开aspnet_Users表就可以可以看到这些。
如果把这个程序配置成运行在/website8虚拟目录下那么一切都没有问题。但是如果它被copy到其他的地方或服务器上并且更换了虚拟路径(比如说“/app1”或更通常被设置的“/”)后,当Membership APIs被使用时他们就“看”不到数据库里已有的用户了——因为他们将会使用一个不同的applicationName去数据库里寻找用户,相应地过滤application_Users表中的用户。这就是为什么会出现上面错误的原因。
如何解决这个问题:最简单的办法是打开ASPNETDB数据库中的aspnet_Users和aspnet_Application表,去“回想”(figure out,因为那时候我们的虚拟目录叫什么名字我们恐怕已经忘了)创建用户和其他数据的时候的程序名称(去aspnet_Application表中查找)
然后打开你的web.config文件,添加一个applicationName属性到provider声明的地方并且给他赋值,例如,下面的代码我们把它设置为在aspnet_Application表存在的/website8:
< membership > < providers > < clear /> < add name ="AspNetSqlMembershipProvider" type ="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName ="LocalSqlServer" enablePasswordRetrieval ="false" enablePasswordReset ="true" requiresQuestionAndAnswer ="true" requiresUniqueEmail ="false" passwordFormat ="Hashed" maxInvalidPasswordAttempts ="5" minRequiredPasswordLength ="7" minRequiredNonalphanumericCharacters ="1" passwordAttemptWindow ="10" passwordStrengthRegularExpression ="" applicationName ="/website8" /> </ providers > </ membership >这样程序就能正常的工作,无论我们部署这个程序到那个虚拟目录。
当然,我们还要保证Roles、Profile、WebPartPersonalization或其他的我们配置的providers也要被配置了。
这样我们的程序可以正常工作了。
如果在一开始就避免它:避免这个问题的最好的办法是始终设置applicationName的值。一个比较好的默认值是使用“/”。
在这里谢谢 范肖维大虾翻译的这篇文章,我才走出了郁闷……
谢谢!