Hi everybody, my first post here...

I've read lots of things on msdn and I still can't make my mind - is it better to use default providers that asp.net offers and rely on the this whole default authentication&authorization system or rather make an effort and write everything from scratch (custom providers, etc)? I like the feeling I wrote every single line in my app, but if the default system is really good then writing own code would be pointless.

The website I'm starting to work on is some kind of a homepage for our group at the university, with ideas like forum to ask about study-related problems, ability to write own blogs and so on.

My question is - what do you recommend? The default asp.net authentication&authorization system or my own tables in database and my own custom providers to manage them?

Greets from Poland,
dar0. 

Here is my point of view on this topic:

If the built in Membership and Role providers meet your needs, then use them.  As much as we as developers love to write our own code, sometimes it is best to use someone else's (in this case Microsofts) if it meets our needs.  One of the biggest positives of this is that it is less code for you to write and debug and one less point of failure in your application.

I have worked pretty extensively with the built in Membership and Role provider, and have only found the need to customize it for one application.  This was because we needed a parent/child relationship for our roles and the ability to use the role table as a taxonomy for one of our web apps.   Overall the built in Membership/Role provider is very robust and should meet many peoples needs right out of the box providing you are using SQL Server. 

Good luck on the application, sounds like a good concept for a University!

Dave G.

Hi,

If you will use the default providers then you have to use the database that comes with it. If you want to add extra information about your users then you have to use profiles to do that. if this suites your requirements then writing new code will be extra effort.

If you think that you will need these extra information to go into your users table because of security/performance issues with profiles then you need to implement your own providers.

Regards

Big thanks for 2 fast replies!

@davidmginn - that's a good news to hear that someone worked with built-in features on several projects with success.

@mr.aspdotnet - that's exactly what made me unconvinced to the default system: is it better to store every user detail in Users table or divide things into Users and Profiles tables? Reading info from Profile table is (if I'm correct) easy inside the code, just have to write someVar = Profile.PropName ; If I kept everything in Users table than I would have to access things like this:  

MyUser u = (MyUser)Membership.GetUser() ;
u.PropName = .... ;

Everybody has it's own preferences, for me Profile.PropName looks nicer and cleaner.

Could anyone answer the underlined question?... 

Hi,

I found these information about profiles in (Pro ASP.NET 2.0 in C# 2005 by Matthew MacDonald and Mario Szpuszta)

From a performance standpoint, profiles work best when the following is true:

• You have a relatively small number of pages that access the profile data.
• You are storing small amounts of data.

They tend to work less well when the following is true:

• You have a large number of pages that need to use profile information.
• You are storing large amounts of data. This is particularly inefficient if you need to use only some of that data in a given request (because the profile model always retrieves the full block of profile data).

Regards