Membership with asp 2.0

[Coder]

I am not sure if I should use the new membership and roles feature in
ASP.NET 2.0. My user information is large, and does not fit in the
default implementation tables. I don't know if it is worth coding my
own provider.

Linking the my user table to the ASP user table might not be protected
with a transaction. I am wondering what people out there do when they
have large user information and want to use security with ASP.NET
membership and roles.

[Cowboy \(Gregory A. Beamer\)]

First, I would NOT store it in profile, as so many examples show.

Custom Provider? This is a great choice, as you get the framework, but also
get what you want. Plan it out well before you start, however, or you are
going to end up having nightmares.

Roll your own? This is an option, but generally the custom provider,
provided you have it lined up and there is nothing inherently incompatible
with the provider model, is easier to maitain.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com

*************** *************** *************** ****
Think outside of the box!
*************** *************** *************** ****
"Coder" <mi*********@gm ail.comwrote in message
news:11******** **************@ m73g2000cwd.goo glegroups.com.. .

>I am not sure if I should use the new membership and roles feature in
ASP.NET 2.0. My user information is large, and does not fit in the
default implementation tables. I don't know if it is worth coding my
own provider.

Linking the my user table to the ASP user table might not be protected
with a transaction. I am wondering what people out there do when they
have large user information and want to use security with ASP.NET
membership and roles.

[Coder]

I agree about the profiles. I am not planning to store data there.

I think I will roll my own functions. At the end it is better to be
specific to my needs then too generic.
Cowboy (Gregory A. Beamer) wrote:

First, I would NOT store it in profile, as so many examples show.

Custom Provider? This is a great choice, as you get the framework, but also
get what you want. Plan it out well before you start, however, or you are
going to end up having nightmares.

Roll your own? This is an option, but generally the custom provider,
provided you have it lined up and there is nothing inherently incompatible
with the provider model, is easier to maitain.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com

*************** *************** *************** ****
Think outside of the box!
*************** *************** *************** ****
"Coder" <mi*********@gm ail.comwrote in message
news:11******** **************@ m73g2000cwd.goo glegroups.com.. .

I am not sure if I should use the new membership and roles feature in
ASP.NET 2.0. My user information is large, and does not fit in the
default implementation tables. I don't know if it is worth coding my
own provider.

Linking the my user table to the ASP user table might not be protected
with a transaction. I am wondering what people out there do when they
have large user information and want to use security with ASP.NET
membership and roles.

[Cowboy \(Gregory A. Beamer\)]

I would bite the bullet and go with the custom provider. You can use MS's
tables as a starting point and gain the use of their framework.

BTW: We have tried, due to schedule, to bolt onto the default MS provider.
It is a royal pain in the butt when you step outside of that box. I would
advise a custom provider over the pain we have discovered. In fact, I would
go custom provider day 1, based on this experience, as someone always seems
to add functionality to membership.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com

*************** *************** *************** ****
Think outside of the box!
*************** *************** *************** ****
"Coder" <mi*********@gm ail.comwrote in message
news:11******** *************@m 73g2000cwd.goog legroups.com...

>I agree about the profiles. I am not planning to store data there.

I think I will roll my own functions. At the end it is better to be
specific to my needs then too generic.
Cowboy (Gregory A. Beamer) wrote:

>First, I would NOT store it in profile, as so many examples show.

Custom Provider? This is a great choice, as you get the framework, but
also
get what you want. Plan it out well before you start, however, or you are
going to end up having nightmares.

Roll your own? This is an option, but generally the custom provider,
provided you have it lined up and there is nothing inherently
incompatible
with the provider model, is easier to maitain.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com

************** *************** *************** *****
Think outside of the box!
************** *************** *************** *****
"Coder" <mi*********@gm ail.comwrote in message
news:11******* *************** @m73g2000cwd.go oglegroups.com. ..

>I am not sure if I should use the new membership and roles feature in
ASP.NET 2.0. My user information is large, and does not fit in the
default implementation tables. I don't know if it is worth coding my
own provider.

Linking the my user table to the ASP user table might not be protected
with a transaction. I am wondering what people out there do when they
have large user information and want to use security with ASP.NET
membership and roles.

[Registered User]

On 31 Oct 2006 09:20:49 -0800, "Coder" <mi*********@gm ail.comwrote:

>I am not sure if I should use the new membership and roles feature in
ASP.NET 2.0. My user information is large, and does not fit in the
default implementation tables. I don't know if it is worth coding my
own provider.

One way or the other you will end up coding something.

>Linking the my user table to the ASP user table might not be protected
with a transaction. I am wondering what people out there do when they
have large user information and want to use security with ASP.NET
membership and roles.

If you write your own provider you will use your own tables, there is
no requirement to use the default datastore. The custom provider will
have to be derived from the abstract MembershipProvi der type and that
public interface is rather limiting. A derived type can also have
additional methods and members that are tailored for your needs. Some
casting will be needed to access the additional functionality

MyExtendedProvi der mxp = (MyExtendedProv ider) Membership.Prov ider;
MyMembershipUse r mmu = mxp.SomeMethod( someArg);

The task is no where near as daunting as it might seem at first
glance.

regards
A.G.

[Coder]

Even if I code my own provider, how would you protect adding users to
roles using Roles.AddUserTo Role(...) and then Adding data to your user
table under the same transaction.

Using Transaction Scope with SQL server is the only way, but then I am
force to use DTC, which is an overkill.

If I decide not to use ASP.NET Roles, then I loose all the
functionality regarding the menu. Still lost!

Cowboy (Gregory A. Beamer) wrote:

I would bite the bullet and go with the custom provider. You can use MS's
tables as a starting point and gain the use of their framework.

BTW: We have tried, due to schedule, to bolt onto the default MS provider.
It is a royal pain in the butt when you step outside of that box. I would
advise a custom provider over the pain we have discovered. In fact, I would
go custom provider day 1, based on this experience, as someone always seems
to add functionality to membership.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com

*************** *************** *************** ****
Think outside of the box!
*************** *************** *************** ****
"Coder" <mi*********@gm ail.comwrote in message
news:11******** *************@m 73g2000cwd.goog legroups.com...

I agree about the profiles. I am not planning to store data there.

I think I will roll my own functions. At the end it is better to be
specific to my needs then too generic.
Cowboy (Gregory A. Beamer) wrote:

First, I would NOT store it in profile, as so many examples show.

Custom Provider? This is a great choice, as you get the framework, but
also
get what you want. Plan it out well before you start, however, or you are
going to end up having nightmares.

Roll your own? This is an option, but generally the custom provider,
provided you have it lined up and there is nothing inherently
incompatible
with the provider model, is easier to maitain.

--
Gregory A. Beamer
MVP; MCP: +I, SE, SD, DBA
http://gregorybeamer.spaces.live.com

*************** *************** *************** ****
Think outside of the box!
*************** *************** *************** ****
"Coder" <mi*********@gm ail.comwrote in message
news:11******** **************@ m73g2000cwd.goo glegroups.com.. .
I am not sure if I should use the new membership and roles feature in
ASP.NET 2.0. My user information is large, and does not fit in the
default implementation tables. I don't know if it is worth coding my
own provider.

Linking the my user table to the ASP user table might not be protected
with a transaction. I am wondering what people out there do when they
have large user information and want to use security with ASP.NET
membership and roles.