Greetings,
I've set up users and passwords in the same manner as on pages 62 and 63 of the ASP.Net Security, Membership, and Role Management.

I am securing specific directories for specific users. The authorization is working fine on Server 2003.

My concern is that I have SQL Express 2005 running on the server and ASP.Net 2.0 puts the default connectionString to ASPNETDB.MDF in the ASP.Net properties of the website.

Since I am NOT using ASPNETDB.MDF for this website, what should I do about the default connectionString ASP.Net adds to the properties.

I put this in my web.config file:

<connectionStrings>
  <remove name="LocalSqlServer">
</connectionStrings>

The authentication/authorization seems to work with or without the above code in web.config. Should I use the above block or take it out?

Also, if I add another website in addition to this one in IIS that DOES use SQL Express and the default connectionString, will this interfere with the functionality of the two sites?

Thanks much. And I'd like to add that this is a great book, worth every penny I paid for it and then some. A great resource for learning this stuff.

You are doing the right thing. Removing the connection string entry in your local web.config is fine. You can then redefine to something that makes sense for you application:

<connectionStrings>
  <remove name="LocalSqlServer">
  <add name="LocalSqlServer" connectionString="something else" />
</connectionStrings>

One thing to be sure of is that in IIS your directory structure is actually marked as an application. When you mention that your existing changes don't seem to take effect I'm wondering if your code hasn't been marked as an application in IIS. That would potentially cause ASP.NET to not pick up your changes.

For each additional website you add in IIS, by default they will inherit the default connection strings settings (i.e. the Sql Express connection string). You can change this in each subsequent application with the same technique of removing and re-adding the connection string with the value that makes sense for each application.

-Stefan

Many Thanks Stefan!

What I'm saying is that it works with or without the <remove name="LocalSqlServer"/> which I assume to be correct because I have no database to attach.

This site using <credentials> has the website root set to "Read and Scripting Only" in IIS and is marked as "Default Application". I have wildcard mapping set at the root via aspnet_isapi.dll.

I have one virtual directory that was created after "wildcard mapping" was set on the root. The secured directories are physical directories under the virtual directory.

The virtual directory application name is grayed out and says "Default Application". I have the virtual set to "Read and Directory Browsing" only.

In this site, I add users and passwords in web.config under <credentials> and NOT using ASPNETDB.MDF or SQL Express. I added the following block to remove "LocalSqlServer" since I'm not using SQL Express with this site. No other connectionString code is present.

<connectionStrings>
  <remove name="LocalSqlServer"/>
</connectionStrings>

For the other membership site which DOES use ASPNETDB.MDF with SQL Express, I'm using the default connectionString from machine.config. I have no connectionString code in web.config or anywhere else for this second site.

Both sites appear to work just fine. The authorization is restricting access as designed.

Is this proper use of authentication and authorization?

How many membership sites can you use with SQL Express with "User Instances" enabled?

Thanks much and I appreciate your help.

For the site using the <credentials /> element the provider-based features won't be called. Usernames and passwords in <credentials /> are authenticated via FormsAuthentication.Authenticate, which doesn't make use of Membership or Role Manager.

Sql Server Express (SSE) is configured by default for development-time use. The default connection string for the .NET Framework uses an SSE mode called user instancing. This usually requires an interactive user logged in and using a tool like Visual Studio.

Its definitely a bit outside my area of expertise, but I think SSE's user instancing will sort of work "by accident" on production servers. What happens is that web servers frequently run with the same process account (e.g. NETWORK SERVICE on Windows Server 2003) - as a result SSE spawns a child sqlservr.exe instance running with that account identity. Then all ASP.NET applications on the web server that are running with the same process account end up using the same user instance.

If the intent is not to have multiple web applications all sharing the same SSE user instance, the recommended approach to using SSE in production is to turn off user instancing. From what I recall there is a Sql hoster toolkit which enables developers to instead upload SSE databases from their developer desktops to a target production environment (http://www.codeplex.com/sqlhost).

Alternatively you should be able to detach the SSE database in development, and then copy it and re-attach it on the production server that is hosting SSE for your production servers. In that mode of operation SSE is just a mini-version of the full Sql Server. So its no different than copying an MDF around between different Sql Server machines and re-attaching databases on those machines.

-Stefan

Thank you Stefan, you cleared up a lot for me. I've been messing around with "User Instances" disabled and added SQL Authenticated Logins to SSE and using a connectionString with:

Integrated Security=false
Initial Catalog = somePath
User ID = someUser
Password = somePassword

I had 3 or 4 test sites running simultaneously with User Instance disabled and connecting with SQL Logins, Everything seemed to work just fine.

But anyway I just want to use two sites like the two I described above. The stickiest time I've had with SSE is getting the permissions set right so it works at all.

Thank you so much for helping me get some of this clear. I've played with it for a while and it looks like I've been on the right path.

Again, Thank You very much and I do appreciate it a lot.