I have a simple CLI app to create/update/delete users of an SqlMembershipProvider. It works, and I can validate just fine from the CLI app.
As soon as I try to do it from the related asp.net app, however, it fails. I've literally copy/pasted the relevant web.conf/app.config sections, so I have no clue why it's failing.
<machineKey validationKey="C94FA3782AAF21E932CAA92DC2A0641951E3A76E50DD25B19C627BA01E259C6CBC7839A7803A59EF3BF855152369A6AB10CC259513BE7ACA4E842B962FD1D8A4"
decryptionKey="2EA6D270AD94361ECFDCED5070D76FD67D9A147FEEBC8388FE9B73B450A04560"
validation="SHA1"
decryption="AES" />
<membership defaultProvider="MembershipProvider">
<providers>
<add name="MembershipProvider" type="System.Web.Security.SqlMembershipProvider"
connectionStringName="ApplicationServices"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
requiresUniqueEmail="false"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="1"
minRequiredNonalphanumericCharacters="0"
passwordAttemptWindow="10"
passwordStrengthRegularExpression=""/>
</providers>
</membership>
This is in both the web.config and app.config, can someone explain why this will validate in the CLI project and not the asp.net project?
And to be clear, here is the code that isn't validationg
Membership.ValidateUser("fake", "fake") // actual test un/pwd combo
I've verified that the un/pwd is in fact correct.
Without knowing anything else about you applications, it seems that the most likely issue is the applicationName attribute in the membership/providers/add node in the config files. See http://msdn.microsoft.com/en-us/library/system.web.security.membership.applicationname.aspx
These applications are probably defaulting to separate application names/identifiers. So when you attempt to login through the web app the provider only sees access granted to the CLI app. The CLI app may not have access to the web root or virtual path info (with no http context) to create a default name so it is probably defaulting to something different than your web app applicationName.
Look at this link for a good explanation: http://weblogs.asp.net/scottgu/archive/2006/04/22/Always-set-the-_2200_applicationName_2200_-property-when-configuring-ASP.NET-2.0-Membership-and-other-Providers.aspx
You can handle this in two ways:
Try setting the applicationName to the same string in both configurations.
OR
Ensure that there are two entries for the user "fake" in the aspnet_Membership table. One for the CLI app and one for the Web app. You should find the applicationID for each application listed in the aspnet_Application table.
Here is another reference where someone used the SqlMembershipProvider outside of an asp.net app: http://mdrasel.wordpress.com/2011/02/01/asp-net-membership-provider-outside-of-web-application/. Note the use of the applicationName attribute.
Related
I have an MVC4 project which was upgraded from MVC2. While debugging with the VS development server the user validation works fine. But when I tried to debug with Local IIS the login fails, because of a wrong password.
On the production system the user validation also works fine.
The only difference between the development server / production system and local IIS is, that the website is running in an virtual directory on local IIS. So the URLs are
on development server / production something like:
http://localhost:12345/ OR http://the.production.server/
but on local IIS it is somthing like:
http://localhost/mymvcproject/
If I move the website to the root directory on local IIS the login works fine.
In the web.config membership is configured like:
<membership>
<providers>
<add name="AspNetSqlMembershipProvider" type="System.Web.Security.SqlMembershipProvider, System.Web, Version=4.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" connectionStringName="ApplicationServices" enablePasswordReset="true" passwordFormat="Encrypted" requiresQuestionAndAnswer="false" requiresUniqueEmail="false" maxInvalidPasswordAttempts="50" minRequiredPasswordLength="6" passwordAttemptWindow="10" applicationName="/" />
</providers>
</membership>
I think the problem is the applicationName parameter, but I haven't changed it.
Things I checked:
the database data were always the same
to create and validate an new user does work on local IIS when in virtual directory
I tested it also with the original MVC2 project, same problem
Am I on the right path?
Is there a way make validation/password encryption/decryption independend from the URL/application name?
Is there a way make validation/password encryption/decryption
independend from the URL/application name?
No. Instead, ASP.Net Membership provider uses Machine Key (in addition to salt) to encrypt and decrypt a password.
Normally, you want to include a machine key in application's web.config explicitly to avoid that kind of saturation.
If you know the machine key, save that in Local IIS's web.config explicitly.
If you do not know the machine key, use the following method to retrieve it.
http://aspnetresources.com/blog/how_to_read_auto_generated_machinekey
Update: 7/9/2013
If you do not assign machine key explicitly, the application will use the auto-generated key by default.
I solved it. Thanks to #Win, you pushed me to the machine key. Just to make it clear, I know the machine key.
I did not see the little IsolateApps parameter in the machine key setting, which is the "key".
With a machine key configured like this:
<machineKey validationKey="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX,IsolateApps" decryptionKey="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX,IsolateApps" validation="AES" />
I have the behavior like I described in my question. But without the IsolateApps like this:
<machineKey validationKey="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" decryptionKey="XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX" validation="AES" />
Everything works fine, no matter if the application is in root or a virtual directory. But there's a catch! I you change the machine like this (not the values, only remove the IsolateApps parameter), the user validation fails for existing users. Only new created users can be validated.
The according MSDN page is http://msdn.microsoft.com/en-us/library/vstudio/w8h3skw9(v=vs.100).aspx.
I have an application on AppHarbor, and I've finally gotten it to work. One thing that's eluded me though is getting my Membership provider to work. I'm using MongoLab for my database, and it works fine with the rest of my application. When, I I try to use Membership, I get this error:
Unable to connect to server localhost:27017: No connection could be made because the target machine actively refused it 127.0.0.1:27017.
And the offending line is in web.config:
<add name="MongoDBMembershipProvider" type="MongoDB.Web.Providers.MongoDBMembershipProvider"....
Could someone please shed some light on my situation?
As friism mentions, you need some code to read the connectionString from an appSetting. Thankfully osuritz has already done the work in a fork of MongoDB.Web on github.
You will need to download the above fork, build & change your existing dll reference to use the new dll.
Then...
change your config:
<appSettings>
<add key="MONGOLAB_URL" value="mongodb://localhost/ASPNETDB"/>
</appSettings>
... the above value will get replaced by appharbor/mongolab (and if you have other parts of the app that work, then this is correct)
<providers>
<clear />
<add name="MongoDBMembershipProvider" type="MongoDB.Web.Providers.MongoDBMembershipProvider"
applicationName="/" appSettingsConnectionStringKey="MONGOLAB_URL" collection="Users"
enablePasswordRetrieval="false" enablePasswordReset="true" requiresQuestionAndAnswer="false" requiresUniqueEmail="false"
maxInvalidPasswordAttempts="5" minRequiredPasswordLength="6" minRequiredNonalphanumericCharacters="0" passwordAttemptWindow="10" />
</providers>
So in the above config, it has the appSettingsConnectionStringKey parameter. The code within the customised provider, reads the appSettingsConnectionStringKey value 'MONGOLAB_URL' and then uses that to read the ConfigurationManager.AppSettings["MONGOLAB_URL"] and it obviously, MUST match the appsetting Key name above.
In the <membership defaultProvider="MongoMember"><providers><add connectionStringName="foo"> you probably need to specify the name of the connectionstring that has you MongoLab connection. Unfortunately, that's not inserted in the connectionstrings element, it's in appSettings. You should probably figure out some way to get the provider to read the connectionstring out of appSettings.
Would suggest to use this project for your purpose http://extmongomembership.codeplex.com/. It supports using of AppHarbor out-of-the-box.
Just need to add useAppHarbor="true" to provider settings as written here https://extmongomembership.codeplex.com/wikipage?title=AppHarbor%20Integration&referringTitle=Documentation
Note: This is port of new Membership Provider that was presented in ASP.NET MVC4
This is sort of a two part question. So I'll start with the first which will lead into the second. I'm hosting a site at GoDaddy where at the root is the main web application. However in a sub-folder I have created a second web application. Both of which use Forms Authentication backed with ASP.NET Membership on a shared database. Meaning both are using the database aspnetdb. What I'm trying to accomplish is the ability to log into one and therefore be logged into both. A Single Sign On (SSO) if you will. What I have found so far is if the applications are on the same server (IIS instance) they therefore share the same MachineKey. From what I have found and from my understanding Forms Authentication uses the MachineKey to generate the Authentication Ticket. So therefore should be no modifications necessary as long as the application name for the Membership, Role and Profile providers match.
Am I accurate so far?
But I have not been able to get this to work. So I tried two other ideas with no prevail.
I added the following to both Web.config files (separately, not together of course).
<machineKey decryptionKey="AutoGenerate"
validation="SHA1" validationKey="AutoGenerate" />
or
<machineKey
validationKey="93A258D47F48AF07AB8BE3EF56C9D32897B9C458F2E14DB6F9AA47D77E40F4CA763D4BD56C2900B507073023F4C43C583A1F7086C2DD327C879368B0449EFB10"
decryptionKey="6BE371E3CDE768B71D0D261370127BAE094984D207EFD4B55FB24384FE1795D1"
validation="SHA1" decryption="AES" />
Generated from http://aspnetresources.com/tools/machineKey
And an example Membership configuration
<membership
defaultProvider="SqlProvider"
userIsOnlineTimeWindow="20">
<providers>
<remove name="AspNetSqlProvider" />
<add name="SqlProvider"
type="System.Web.Security.SqlMembershipProvider"
connectionStringName="aspnetdb"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="true"
passwordFormat="Hashed"
applicationName="/" />
</providers>
</membership>
So my first question, will this work and am I on the right track? Because I have not been able to get this to work.
The next question is, if this works and someone were to download an application and load it to their website. And, if in the application Web.config the MachineKey is specified, like the one generated above, and they leave the default application name, like '/', could this be a security risk? Meaning if person A loaded an app and person B loaded the same app could a user authenticate on one and therefore be authenticated on the second installation. Mind you person A and person B have no relationship other than they both loaded the same application and left it with the default settings.
References:
http://msdn.microsoft.com/en-us/library/ff649308.aspx
http://help.ablecommerce.com/faqs/ablecommerce_7/how_do_i_install_to_a_shared_hosting_environment_.htm
http://rtur.net/blog/post/2009/03/30/Using-machineKey-with-ASPNET-Membership.aspx
Using one Asp.net Membership database with multiple applications Single Sign On
[Update]
- I'm determined to find the solution to this issue soon. If you are also search for a solution stay tuned...
I am just wondering
why did asp.net team choose / as the default value of Membership Role application name rather than the project name that makes sense?
In addition, the application might not be deployed as the root application. It means that / is no longer appropriate.
Edit 1:
For example: I create a project A first and deploy it. Later I create another project B and deploy it. If both projects use the default, they still work but it will be difficult to know which users come from each project.
For me, it is better if the default is set to the project name.
Edit 2:
I am talking about the applicationName attribute generated by Visual Studio in Web.config.
Why don't use the project name instead of / by default ?
<membership>
<providers>
<clear />
<add name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider"
connectionStringName="ApplicationServices"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
requiresUniqueEmail="false"
maxInvalidPasswordAttempts="5"
minRequiredPasswordLength="6"
minRequiredNonalphanumericCharacters="0"
passwordAttemptWindow="10"
applicationName="/" />
</providers>
</membership>
<profile>
<providers>
<clear />
<add name="AspNetSqlProfileProvider"
type="System.Web.Profile.SqlProfileProvider"
connectionStringName="ApplicationServices"
applicationName="/" />
</providers>
</profile>
<roleManager enabled="false">
<providers>
<clear />
<add name="AspNetSqlRoleProvider"
type="System.Web.Security.SqlRoleProvider"
connectionStringName="ApplicationServices"
applicationName="/" />
<add name="AspNetWindowsTokenRoleProvider"
type="System.Web.Security.WindowsTokenRoleProvider"
applicationName="/" />
</providers>
</roleManager>
EDIT 3:
After creating two applications (i.e., one as the root and the other one as the child app) and both have the same applicationName set to /, both application use the same ApplicationID. It means the slash has nothing to do with site domain tree. My confusion has been answered. So... why did Visual Studio set it to / (that makes confusion for me) by default?
EDIT 4:
I have two applications. One as the root application and the other one as the sub application under the former. Both use applicationName = "/". I got the result as follow in database: So what is the meaning of /? If no meaning, why did VS choose this confusing name rather than the project name?
EDIT 5:
From this article, I will make the summary:
If we remove applicationName attribute from web.config for both applications, the ApplicationName generated in database for the root will be "/" and the ApplicationName generated in database for the sub app will be "/subappvirtualdir".
If we leave the applicationName to its default value of "/" for both applications, both root app and sub app will get the same ApplicatonName of "/" generated in database.
If we change the applicationName to "any name you want" for both applications, the ApplicationName generated in database will be set to "any name you want" for both applications.
Thanks Rockin for the link above !
I'd say that the default name is / because your DB is not supposed to know anything about your app. Therefore it doesn't know the project name. They have to have some sort of starting point, and since they're not mind readers, you get a /.
Remember, since you can use Aspnet_regsql.exe to create your ASP.NET Membership Scheme in your database completely independent from Visual Studio, the database can't just "fix" the application name all on it's own. You can of course edit the app name in the database immediately after creating the db, then it doesn't matter anymore.
EDIT
I see in your edit that you're talking about the applicationName in the web.config, and not the one in the database. Please read this blog article (not mine) for some more insights
http://dotnettipoftheday.org/tips/applicationName_attribute.aspx
An application does not generally know or care what 'project' it came from. So that context likely would not be present.
And if your app isn't at the root, then rename it...
I have two asp.net applications on one IIS server and I would like to use the same back end asp_security database and membership provider. I've read that all I have to do is reference the same application name in both web configs as I'm doing now, but I must be doing something wrong
In each applications web.config I have this section.
<membership>
<providers>
<clear/>
<add name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="membership"
enablePasswordRetrieval="false"
enablePasswordReset="true"
requiresQuestionAndAnswer="false"
applicationName="/"
requiresUniqueEmail="false"
minRequiredPasswordLength="5"
minRequiredNonalphanumericCharacters="0"
passwordFormat="Hashed"
maxInvalidPasswordAttempts="5"
passwordAttemptWindow="10"
passwordStrengthRegularExpression=""
/>
</providers>
</membership>
When I log in from application A and browse to application B application B doesn't seem to know anything about me or my credentials from application A. Anyone have any ideas what I'm doing incorrectly?
Just for closure sake I will answer how I did achieved the goal of what my original question meant to ask for.
I had two asp.net applications on one IIS server. It was my goal to make it so when user logged onto app1 their user credentials would be available in app2. Configuring the asp.net membership provider is only one step of what I was looking for. Even if both apps were using the same back end database and provider I still wouldn't be authenticated when I hit app2. What I was looking for was a Single Sign On solution.
Once you have both apps pointing at your asp_membership database by placing the following in the system.web section of your web config
<authentication mode="Forms" />
<membership>
<providers>
<clear/>
<add name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="membership"
applicationName="/"
/>
</providers>
</membership>
<roleManager enabled="true" />
make sure both have the same applicationname property set.
I was using IIS 6 so I configured it to autogenerate a machine key for both applications. Because both of these applications live on the same machine the key would be identical, this is the critical part to making the SSO work. After setting up IIS the following was added to my web.config
<machineKey decryptionKey="AutoGenerate" validation="SHA1" validationKey="AutoGenerate" />
That was all there was to it. Once that was done I could log into app1 and then browse to app2 and keep my security credentials.
Thanks for the push in the right direction.
If my understanding serves me correctly, the users authentication credentails are stored within the HTTP context of each application. So switching between the two applications will not automatically authenticate the user, since a new context will be created when you switch to app B.
What I believe may the correct approach would be to use the DefaultCredentials (or UseDefaultCredentials property to True) of the current user prior to switching to app B.
When you say switch what do you mean eg. open a different browser window and access app B or request a page from appB from appA?