Help with ASP.NET Memberships

[Jonathan Wood]

I'm taking my first stab at using ASP.NET memberships and could use some
help.

I'm following along in a book, which recommends I use the Web Application
Administration Tool in VS 2005.

A couple of problems:

1. The only choices it gives me for the authentication method are Windows
and Passport. Based on what I read, forms is what I need. Can anyone tell me
why this option isn't available?

2. I see it generated a complete, new database to store the membership
information in. That's okay I guess but doesn't it have the option of
storing those tables in my main database? Is it the standard to create a
separate database? Most of the data I need to store will be associated with
the users and so I assume I'd want to combine database and be able to extend
the user information that ASP.NET created. Am I off-track here?

Thanks for any help.

 

[Scott M.]

You should have two choices for authentication: Forms(passport) or
Windows(active directory). It seems that you are getting these two choices.

The database that is needed to manage the memberships is quite sophisticated
and is much more than just a table of users and their access levels. You
would not want to merge this data with data of your own. Having said that,
the default storage mechanism for the membership database is SQL Server
Express Edition (which is included with VS 2005). You can change this so
that the database is set up within an existing instance of SQL Server or
even other provider that you have on your system. This, however is not as
simple as just changing a setting. It involves changing values in your
web.config and possilby machine.config files for VS 2005 as well as creating
the membership database itself within the provider you wish to use.

But to sum up, using the membership database in conjunction with your own
extesions of that database is not a good idea.

-Scott

 

[Phil H]

Dear Jonathan

The ASPNETDB database that is created can support multiple
applications. It has been designed to act as a common resource. One of
the fields in the tables is "Application ID"

It is not true that only Windows and Passport modes of authentication
are supported. It does indeed support Forms mode, in fact there are
special web controls for it e.g. the Login control which is available
in the toolbox of the VS2005 designer.

If you want to integrate the membership database with your application
database then the easiest way is to add your own tables etc to the
ASPNETDB database. The latter can be renamed to something else but you
will need to ammend the web.config file accordingly.

I'm afraid it's all too complicated to deal with here, I suggest you
study it further and give yourself a chance to absorb it all before
trying to implement it in an actual project. There are a lot of other
issues that need to be addressed, not the least is whether you can use
the default mode of access via so called "User instances" where
the .mdb file is attached "on the fly" to the SQL server, or whether
you set it up as a permanently attached database (SQL 2005 Express
edition will support it).

Having said that it's a great tool for controlling who can do what and
the various views that different users can have of the site and its
resources. It's well worth persevering with.

HTH

 

[Jonathan Wood]

Scott,

You should have two choices for authentication: Forms(passport) or
Windows(active directory). It seems that you are getting these two
choices.

Ack! Well, running it again I see the wording is how will users access the
site and the choices are from the Web or from a local network. Selecting
'from the Web' does indeed seem to implement forms authentication mode. I
guess I didn't quite get what it was doing before.

The database that is needed to manage the memberships is quite
sophisticated and is much more than just a table of users and their access
levels. You would not want to merge this data with data of your own.

But as I mentioned before, the only data I really need to store is some
additional information about the users. Are you recommending I create a new
database so that I have two different databases that store my users' data?

Note: My site will be hosted on a shared hosting service.

Thanks.

Jonathan

 

[Jonathan Wood]

Phil,

The ASPNETDB database that is created can support multiple
applications. It has been designed to act as a common resource. One of
the fields in the tables is "Application ID"

Yeah, I see that. The problem is that my site will be hosted on a shared
hosting service. And I have no reason to associate more than one site with
the membership database.

It is not true that only Windows and Passport modes of authentication
are supported. It does indeed support Forms mode, in fact there are
special web controls for it e.g. the Login control which is available
in the toolbox of the VS2005 designer.

I guess I didn't quite get what the Web Application Administration Tool was
doing. Reviewing that, it appears to be implementing forms authentication
okay.

If you want to integrate the membership database with your application
database then the easiest way is to add your own tables etc to the
ASPNETDB database. The latter can be renamed to something else but you
will need to ammend the web.config file accordingly.

Let me ask you this: if your application data is primarily information about
your users, would keep the two databases separate or merge them?

I would have thought not only that both data would go into the same
database, but that ideally I could add fields to the user data in the
membership database. Is that not the approach you'd take?

I'm afraid it's all too complicated to deal with here, I suggest you
study it further and give yourself a chance to absorb it all before
trying to implement it in an actual project. There are a lot of other
issues that need to be addressed, not the least is whether you can use
the default mode of access via so called "User instances" where
the .mdb file is attached "on the fly" to the SQL server, or whether
you set it up as a permanently attached database (SQL 2005 Express
edition will support it).

Having said that it's a great tool for controlling who can do what and
the various views that different users can have of the site and its
resources. It's well worth persevering with.

I don't have much choice. I need to implement the site now. My understanding
is that user instances are bad, but I'm not thinking that will be an issue
for me.

I guess I can just create a separate database and store my data there is
that will be simpler. I just thought that would be a big waste is space and
performance.

Thanks.

Jonathan

 

[Scott M.]

Are you recommending I create a new database so that I have two different

databases that store my users' data?

No, you could create new tables in the membership database if needed, but I
wouldn't mess with any of the auto-generated stuff.

 

[Jonathan Wood]

I just want to make sure I understand.

So you don't see any need for a separate database, but that I should add
separate tables for storing my application's user data, even if there is
some overlap. Is that correct?

At this point, I should probably take the path of least resistance.

Thanks.

 

[Scott M.]

Correct. Also, I don't see any problem with creating relationships in your
new table(s) with existing data. Also, I'm not sure what data (if any) in
the auto-generated tables may be encrypted or hashed, so you may run into
issues deciphering the data (I'm not sure).

 

[Guest]

I don't understand the FUD that seems to be going on here. You create the
ASP.NET Membership, Roles and Profiles database schema in *ANY* database you
want via the ASPNET_REGSQL.EXE utility. You can also do it programmatically
with methods in the System.Web.Management namespace, e.g.:
Management.SqlServices.Install("server", "USERNAME", "PASSWORD",
"databasename", SqlFeatures.All)

http://www.eggheadcafe.com/articles/20060529.asp

-- Peter
Recursion: see Recursion
site: http://www.eggheadcafe.com
unBlog: http://petesbloggerama.blogspot.com
BlogMetaFinder: http://www.blogmetafinder.com

 

[Jonathan Wood]

Okay, thanks. It would be a shame though. In my database, some users are
clients and some users are trainers and each client must be associated with
a trainer. So if my data is in separate tables, I need a table just to link
the users to trainers. In addition to the fact that I think that would break
things like cascading deletes, etc., it just doesn't seem like a very good
design.

It looks like you can implement your own provider class. I'll research that
some more as I don't know if that's more than I want to get into now.

Thanks.

 

[Jonathan Wood]

Peter,

I don't understand the FUD that seems to be going on here. You create the
ASP.NET Membership, Roles and Profiles database schema in *ANY* database
you
want via the ASPNET_REGSQL.EXE utility. You can also do it
programmatically
with methods in the System.Web.Management namespace, e.g.:
Management.SqlServices.Install("server", "USERNAME", "PASSWORD",
"databasename", SqlFeatures.All)

http://www.eggheadcafe.com/articles/20060529.asp

I'm not really sure if this was directed at me or which statements,
specifically, constituted FUD in your mind. As you can probably tell, I
haven't been working with ASP.NET very long at all.

From what I've read, you can implement your own provider class. If so, that
sounds like a nice feature but may be more work than I want to take on.

This ASPNET_REGSQL.EXE utility is a new reference to me and I have
absolutely no idea what it does or how it helps one to implement
memberships. I will definitely read the article though.

Thanks.

 

[Kevin Spencer]

Hi Jonathan,

I understand your difficulty. When I had a similar project, I experienced
the same thing. It took me a good bit of research and study to get the ideas
behing the ASP.Net Provider Model, and some of the implementations of it
(Membership Provider, Role Provider, SiteMap Provider) which come packaged
in the framework, but once I "got it" it became fairly simple to use, and I
even ended up writing a Provider of my own which I used for email with
Memberships and Roles in an application.

Part of the confusion may arise from not understanding (as I did not) that
several or all of these Providers may be mixed and matched. For example, in
my project, I used all of them together. The difference between Membership
and Roles is only one of specificity. If you think about how Windows
security works, it is very similar. Membership is similar to individual
users on a system or a domain. Roles are similar to Groups. As a user may be
a member of several Groups, so Members may have many Roles. The link between
these and the SiteMap Provider is that the SiteMap Provider includes support
of restricting both the navigation viewability of sections or individual
pages in a web site, and the ability to directly navigate to sections or
pages in a web site, via the application of Roles and Members to those
sections and pages, via Membership and/or Role Providers.

Another aspect which may cause confusion is that these are all designed to
be highly flexible, and the documentation reflects this. It is not necessary
to use both Membership and Roles, for example, One may use one or the other.
In addition, the storage of Membership and Role data is highly
configurable/flexible, allowing the developer to choose between using XML
configuration files, databases, Windows security accounts, or any other
storage mechanism desired. This is all accomplished via loose coupling
between the provider classes and their backing data stores.

The simplicity comes from a combination of the Provider pattern itself, and
the use of static classes to provide the interface between the application
and the Provider. The Provider pattern dictates that a static class of
static methods is the "intermediary" between the application and the actual
Provider class implementation. The static class acts as a "proxy" for the
implementation, accepting input from the application, passing it on to the
Provider class implementation, getting the response from the implementation,
and returning it to the Application transparently. The application knows
nothing of the actual Provider implementation; the static class finds it via
the configuration file.

It is the implementation that knows where the data store is, and how to
handle the input. There are a very few built-in implementations in the
Framework, but many which can be developed, if one understands the model.
The application knows what to expect from the static class, and as long as
it gets what it expects, it can use any Provider.

At any rate, some articles and sample code might be helpful to you (I know
they were to me), so here are some good links:

http://www.odetocode.com/Articles/427.aspx
http://www.odetocode.com/Articles/428.aspx
http://msdn2.microsoft.com/en-us/library/aa479030.aspx
http://msdn2.microsoft.com/en-us/library/aa478948.aspx
http://msdn2.microsoft.com/en-us/library/aa479031.aspx
http://msdn2.microsoft.com/en-us/library/aa479032.aspx
http://quickstarts.asp.net/QuickStartv20/aspnet/doc/security/default.aspx
http://msdn2.microsoft.com/en-us/asp.net/aa336558.aspx
http://msdn2.microsoft.com/en-us/library/ms998317.aspx
http://msdn2.microsoft.com/en-us/library/ms998347.aspx
http://msdn2.microsoft.com/en-us/library/ms998314.aspx

--
HTH,

Kevin Spencer
Microsoft MVP

DSI PrintManager, Miradyne Component Libraries:
http://www.miradyne.net

 

[Jonathan Wood]

Thanks Kevin,

I'm swamped today but will read your entire message along with the links you
posted.

 

[Scott M.]

This ASPNET_REGSQL.EXE utility is a new reference to me and I have

absolutely no idea what it does or how it helps one to implement
memberships. I will definitely read the article though.

This is the command line command that will create and configure the ASP.NET
membership database in a full-blown version of SQL Server.

But, this is not the only thing you need to do, you still have to change
either your web.config or machine.config files to tell the framework which
provider you want to use.

-Scott