I have a asp.net web project I am working on, and found out my roles and such are stored in an .mdf file. While reading on attempting to connect to it via SQL Management Studio (using SQLExpress 2005), I found this article:
https://help.maximumasp.com/SmarterTicket/Customer/KBArticle.aspx?articleid=878
Now, my question is - should I be doing this? I am going to upload the website to a hosting provider when finished, and would like the process to be as smooth as possible.
Does one normally just move the MDF file to the server along with the website, or is it better to have the information stored inside SQL Server itself? I do have a DB already for the website... can I integrate asp.net's role information into my own DB so that I only have a single DB to manage?
Thanks for reading,
~~Kolten
Using the ASP.NET membership provider is a valid way of managing your user credientials. Uploading the MDF file introduces the risk that someone may be able to get your MDF file and then get all of your users details. Having this stored in a SQL database provided by your hosting environment would usually be more secure, provided that the connection details aren't compromised, and you don't expose your self to SQL Injection attacks and your provider also doesn't expose themselves to SQL injection attacks.
The Membership information can be stored in the same database as the rest of your application as long as there is no name conflicts with the membership tables. You can create the tables required by specifying your database connection details on the aspnet_regsql command line.
Inside your web.config file you will need to modify the roleManager and membership providers so that you can specify the connection string to use. i.e.
<system.web>
<roleManager enabled="true" defaultProvider="AspNetSqlRoleProvider">
<providers>
<remove name="AspNetSqlRoleProvider" />
<add name="AspNetSqlRoleProvider" connectionStringName="MembershipSQLConnectionString"
applicationName="/"
type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</roleManager>
</system.web>
Related
I am working on a project in ASP.NET using MembershipProvider for my login system. Our issue is that the ASPNETDB file generated by ASP.NET upon creation of the login system seems to be empty or is not properly storing member information. Our project is a Web Site project, and we ran into a weird case of not being able to maintain login info. I gave my colleague my ASPNETDB file, he overwrote his and yet the login system was still using his old member information, it would not recognize the new ASPNETDB file. So I'm assuming the issue is that the member information is not being stored in that specific file as I was expecting.
How do we remedy this? We need to install this system for a client, so we will probably host the site sometime soon, how do we localize the membership information so that it's consistent across multiple workstations? Right now the membership info seems to be tied to specific computers. And when we go into the ASPNETDB file there doesn't seem to be anything there.
Can anyone shine some light on this? Its been happening for a while now.
I still don't know how to make it so that it always pulls from the
same location (project directory) instead of SQL server.
In ASP.NET Membership, connection strings for memership and roleManager are in web.config. You just need to update them accordingly.
<configuration>
<connectionStrings>
<remove name="SqlConnection"/>
<add name="SqlConnection" connectionString="..."/>
</connectionStrings>
<system.web>
<membership>
<providers>
<clear/>
<add connectionStringName="SqlConnection" ... />
</providers>
</membership>
<roleManager enabled="true">
<providers>
<clear/>
<add connectionStringName="SqlConnection" ../>
</providers>
</roleManager>
</configuration>
I have an MVC 4 website using .NET framework 4.5 that works fine at first. It allows me to login and go about my business adding, deleteing and editing records. As such, it is obviously initially connecting to the database without a probelm. However, if I leave it inactive for a while and come back at a later time, and then click a link to a page that shows data from my database, I get the following error:
The SSE Provider did not find the database file specified in the connection string. At the configured trust level (below High trust level), the SSE provider cannot automatically create the database file.
The website works fine on my localhost, but not when I host it online. I use shared hosting for this. I've done extensive searching online and found lots of people getting the same error, but they don't seem to have a website that works initially and then suddenly stops working. The solutions I've found online say something along the lines of:
add these two lines to your web.config file
<remove name="LocalSqlServer"/>
<add name="LocalSqlServer" connectionString="Data Source=p3swhsql-v15.shr.phx3.secureserver.net; Initial Catalog=DatabaseName; User ID=****; Password='****';"/>
by default the .net site is trying to find your database in the local filesystem in this case would be the app_data subfolder under the wwwroot directory. simply removing the connectionstring and replacing it with the database connection solves the issue. My example utilizes an SQL db on godaddy's server. however i'm sure you can replace the connection string with the appropriate string for your connection. good luck and i hope this helps anyone that may be having this issue
What my program seems to be doing is using the online database when I first login, and then reverting to trying to use the database in the local filesystem once the session timesout. This is very frustrating. My web.config file looks as follows:
<connectionStrings>
<remove name="DefaultConnection"/>
<add name="DefaultConnection" connectionString="Data Source=winsqls01.cpt.wa.co.za;Initial Catalog=SportFantasySA;Persist Security Info=True;User ID=*****;Password=*****" providerName="System.Data.SqlClient"/>
</connectionStrings>
Please help. I'm desperate to get this working. I understand that it can't create the sql express database in the hosting space, that's why I'm using the connection string for the database on my hosting company's server.
If you have hosted it on Godaddy go for the connection string as
<providers>
<remove name="AspNetSqlMembershipProvider" />
<add name="AspNetSqlMembershipProvider" connectionStringName="LocalSqlServer"
..other attributes here... /></providers>
<connectionStrings>
<remove name="LocalSqlServer"/>
<add name="LocalSqlServer"
connectionString="Data Source=xxxx; Initial Catalog=xxx; User ID=xxx; Password=xxx;"
providerName="System.Data.SqlClient" />
I created a database with aspnet_regsql, the database was created in sql sever 2008 and not in data folder in my project (do I need to move it to the folder manually?).
Next, in Web Site Administration Tool I went to provider section and clicked don Test button.
I got an error:
Could not establish a connection to
the database. If you have not yet
created the SQL Server database, exit
the Web Site Administration tool, use
the aspnet_regsql command-line utility
to create and configure the database,
and then return to this tool to set
the provider.
Maybe I need to set something in a web.config, like membership settings or connection strings (or ASP.NET Website Administrator Tool should create those settings for me)?
Update:
Maybe it happens because I am using SQL server 2008 full and not express?
Update 2:
After setting membership section and connection string to my aspnetdb database in Web Site Administration Tool I've opened security->Security Setup Wizard->Define Roles (stage 4) I got this error:
An error was encountered. Please return to the previous page and try again.
The following message may help in
diagnosing the problem: Unable to
connect to SQL Server database. at
System.Web.Administration.WebAdminPage.CallWebAdminHelperMethod(Boolean
isMembership, String methodName,
Object[] parameters, Type[]
paramTypes) at
ASP.security_wizard_wizardpermission_ascx.OnInit(EventArgs
e) at
System.Web.UI.Control.InitRecursive(Control
namingContainer) at
System.Web.UI.Control.InitRecursive(Control
namingContainer) at
System.Web.UI.Control.InitRecursive(Control
namingContainer) at
System.Web.UI.Control.InitRecursive(Control
namingContainer) at
System.Web.UI.Control.InitRecursive(Control
namingContainer) at
System.Web.UI.Page.ProcessRequestMain(Boolean
includeStagesBeforeAsyncPoint, Boolean
includeStagesAfterAsyncPoint)
Yes, you'll need to modify your connection strings in the web.config.
Look in the web.config, you'll probably see something like this in the <membership> element:
<membership>
<providers>
<clear />
<add connectionStringName="LocalSqlServer"
name="AspNetSqlMembershipProvider"
[...]
type="System.Web.Security.SqlMembershipProvider,
System.Web,
Version=2.0.0.0,
Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</membership>
The connectionStringName Attribute tells the framework to look in your <connectionStrings> element for a connection string called "LocalSqlServer" - this may not be defined in your web.config as it can be inherited from the Machine.Config in the .Net Frameworks core config directory.
You should probably pick a new name for the connection string, and update your membership, roles and profile (if you're using them all) providers to use the new name.
Then in the <connectionStrings> element have the following:
<connectionStrings>
<remove name="LocalSqlServer" />
<add name="MyConnectionString"
connectionString="Data Source=[ServerName];Initial Catalog=[DatabaseName];Integrated Security=True"
providerName="System.Data.SqlClient" />
</connectionStrings>
Adjust the values to suit your systems - I'd recommend Integrated Security over storing your database login and password in the web.config, but YMMV (for example, on my shared host, I can't use Integrated Security, so have to supply user/pass details).
The Web Site admin tool will honour these connection strings as well.
Edit to respond to comment
Have you successfully logged in at all? Or created a user? I just want to rule out that you've the connection string configured and working?
Do you have the Roles Provider configured and turned on as well? Have you updated the "connectionStringName" attribute in there?
Note that as before, the machine.config specifies a default role provider for you that attempts to point to a local SqlExpress instance - which is probably where the connection error is coming from.
<!-- Note enabled="true" - you need to turn this one on! -->
<roleManager enabled="true">
<providers>
<clear />
<add connectionStringName="MyConnectionString"
[...]
type="System.Web.Security.SqlRoleProvider,
System.Web,
Version=2.0.0.0,
Culture=neutral,
PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</roleManager>
For more details on the elided attributes, I'd recommend the documentation:
roleManager Element
providers Element for membership
Once you've configured that, it should all work.
If you've not been able to create a user/log in, I'd check:
The connection string - make sure the names match, make sure the data source matches your server instance (not always just the name of your machine, it might be something like "MachineName\SqlServer").
If you are using integrated security, you will need to ensure that you've given the account your site runs under the appropriate rights in the database: You should find that your database has a number of roles in it starting with aspnet_, to ensure that you can create users (which you'll need if you have a registration form) you should add the account to the aspnet_XXXX_FullAccess roles (one each for Membership, Personalization, Profile and Roles).
Open sql management studio and open the master database, make a new query and type
sp_configure 'user instances enabled','1'
execute this, then type
reconfigure
and execute this too so the changes take effect. For more information on sp_configure you can read http://msdn2.microsoft.com/en-us/library/ms188787.aspx if you wish to list all the configuration then execute sp_configure without any parameters.
Follow the below steps For proper Membership integration to your website(if you see the above error like
"Could not establish a connection to the database. If you have not yet created the SQL Server database, exit the Web Site Administration tool, use the aspnet_regsql command-line utility to create and configure the database, and then return to this tool to set the provider.").
step 1:
Run aspnet_regsql.exe utility from C:\windows\Microsoft.NET\Framework\v2.0.50727 folder on your machine. Selecting or double clicking the aspnet_regsql.exe utility opens the wizard as below.
Selecting Next button on above window opens next window where you can either configure SQL Server for Application services or remove Application services information from an existing database.
step 2:
Select configure SQL Server for application services radio button to install new database and select Next button.
Step 3
Enter your SQL Express server name as as shown below. Note that you can change the application services database name to your desired name (aspnetdb by default).(or) you can select Sql Server authentication (user name,password,respective database name is needed)
Note that i named the database to ASPNETServices
Step 4:
Select Next button and confirm that your settings are correct to go further with installation (shown in below image) and select Next button.
Step 5
Selecting Next button on above window takes you to confirmation window as below after successful installation of your application services database for ASP.NET.Finally press Finish.
Step 6
You will see installed ASPNET Services database ready to use within your ASP.NET application
I've been having similar issues as this is my first time working with asp.net membership. If you set the <roleManager Enabled="False" /> you will be able to get through to creating users.
I'm guessing here, but I think that an additional provider in the web.config for the AspNetSqlRoleProvider and giving it a connection string that points to the asp services database with a user that is setup to access role management information on the SQL side (view the sql user's properties for "schemas owned by this user" and "Database role membership") will allow the tool to get into the DB correctly.
Are you using windows authentication or SQL authentication on your SQL Server?
PS -
The more I read and understand Zhaph's answer, the more I like it. He gave a link to the msdn schema for the AspNetSqlRoleProvider element (don't be fooled by microsoft saying the document doesn't exist, just select an appropriate version from the "other versions" drop down).
Update
I did a bad thing in posting here before actually testing what I was writing, but I did follow through and adding the following to the web.config allowed me to both continue editing users and add/manage roles.
<roleManager enabled="true">
<providers>
<clear/>
<add name="AspNetSqlRoleProvider"
type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"
connectionStringName="MyConnectionString"/>
</providers>
</roleManager>
as i mentioned earlier, the user specified in my connection string required the aspnet_Roles_...Access properties as well as aspnet_Membership_...Access unless you're using integrated security=true along with the <identity impersonate="true" userName="windowsUser" password="winUsrPassword" /> in which case your windows user needs those properties.
I have an ASP.NET v2.0 website (not web application) where the root directory is public, but the "Admin" subdirectory requires authentication. Everything about the setup is very generic - I used a connection string defined in the root web.config, and the standard AspNetSqlMembershipProvider provider, and I'm using the ASP.NET Login control.
The web.config in the Admin directory specifies that the user must have the "Admin" role.
I'm using SQL Server 2008, and my connection string is good; every root level page is data driven and they all work fine.
Provider configuration seems goo.
when I log in, the Login control's "OnLoggedIn" event fires.
The last line in that event code redirects me down to my Admin/Default.aspx page. My breakpoint in "OnLoggedIn" shows me that all's well until the redirect down into my Admin directory...and then...
...and then I wait...and wait...
And then I get an error telling me it's experienced a "SQLExpress database file auto-creation error."
Why in the world is it suddenly trying to create a SQL Server Express file? Why is it suddenly ignoring my connection string?
One odd clue: Just before the last line of the "OnLoggedIn" event I put in this:
bool blnTest = User.IsInRole("Admin");
I wanted to see if blnTest = true.
What happens is the process hits this line...and waits...and eventually tells me it can't access the SQL Server Express database. It seems that any reference (either in my code, or behind the scenes) to determine the User's Role, calls the wrong database.
EDIT: Argh, sometimes it waits when I test blnTest. Other times it immediately reports the value as "false."
According to your comment, it looks like you have haven't explicitly configured a role provider for you site.
If all that's in your web.config is:
<roleManager enabled="true" />
Then you are relying on the default providers declared further up the configuration hieracrchy (machine.config, global web.config, etc)
In machine.config you've probably got something like:
<roleManager>
<providers>
<add name="AspNetSqlRoleProvider"
connectionStringName="LocalSqlServer"
applicationName="/"
type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
<add name="AspNetWindowsTokenRoleProvider"
applicationName="/"
type="System.Web.Security.WindowsTokenRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
</providers>
</roleManager>
As you can see, the first provider is configured to use a connectionString called LocalSqlServer - which is also usually declared in the machine.config:
<add name="LocalSqlServer"
connectionString="data source=.\SQLEXPRESS;Integrated Security=SSPI;AttachDBFilename=|DataDirectory|aspnetdb.mdf;User Instance=true"
providerName="System.Data.SqlClient"/>
And this is designed to use a local file based database that will be created if it doesn't already exist.
So to get roles working on your site, you should ammend your root web.config to something like:
<roleManager enabled="true">
<providers>
<clear />
<add name="AspNetSqlRoleProvider"
connectionStringName="YourConnectionStringName"
applicationName="/"
type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
</providers>
</roleManager>
Using the <clear /> element will remove all previously defined providers for that type.
When you specify the AttachDBFilename option in the connection string you are in fact asking for your-very-own-just-in-time-provisioned SQL Server instance, aka the 'user instance'. This instance is created by asking the 'master' instance (the .\SQLEXPRESS instance) to provision a child instance, which implies copying the master/model/msdb into your profile, starting a new SQL Server process under your account configured to use the freshly copied master/model/msdb, then asking this 'child' instance to attach the specified 'file' as a new database. The details are explained in SQL Server 2005 Express Edition User Instances.
The process of creating a child instance is extremly fragile and when it breaks the DB call results eventually in a time out error when opening the connection. In your case it seems that the process breaks in some cases (when you reach the protected part of the site). Why it breaks, is very hard to guess without proper information. Look at the Common Issues in the linked article and see if any applies to you. Also check the system event log for any message why the child instances cannot start or it cannot open the MDF file. Note that a common mistake is to ask for the same physical file with AttachDBFilename under different credentials: each credential will start its own 'child' instance and only the first one will succeed in attaching the desired database.
I had the same problem which was due to the services for sql server being disabled.
Check under services.msc to see if the sqlexpress service is running. If it is check to see if you have sql express installed on your machine
I have been learning ASP.NET by experimenting, watching videos on ASP.NET, and reading forums. I haven't found a quick solution to this though.
Whenever I add the "login" or "createuserwizard" from the toolbox it always adds the new users to a database known as "ASPNETDB.MDF" even if I specify the remote database using a new SqlDataSource.
Is there an easy way to save the login information? Any tutorials that helped you?
By default, ASP.NET will use a local file based database to store the login information.
If you want to use a different database, you need to do a couple of things:
Set up the Remote Database using aspnet_regsql.exe (usually found in C:\Windows\Microsoft.NET\Framework\v2.0.50727) - running this will start it in GUI mode, allowing you select a server and database to add the tables and stored procs to.
Configure your web site to use this database. There are a few of places you need to do this:
In the ConnectionStrings section of the web.config add your new ConnectionString:
<add
name="zhpCoreContentConnectionString"
connectionString="Data Source=Hobbiton\SqlExpress;Initial Catalog=zhpCoreContent;Integrated Security=True"
providerName="System.Data.SqlClient"/>
In the MembershipProvider section of the web.config, ensure the ConnectionString attribute is set to the same name as your connection string (other settings elided for berevity):
<membership>
<providers>
<add
connectionStringName="zhpCoreContentConnectionString"
applicationName="/doodle"
name="AspNetSqlMembershipProvider"
type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a"/>
</providers>
</membership>
If you are using Roles or Profiles you'll want to ensure that they are also using your connectionstring to store everything together, and ensure that the applicationName attribute is common between them.
This sounds like you need to Implement a Custom Membership user