Membership & Roles ApplicationName

[ePrint]

Asp.Net v2.0
I have created a web application and I am using it from a single website and
database. The web application has different ‘portals’ – each independent and
I am using the Membership & Roles ApplicationName to separate out my
different groups of users within the membership database.

I had been having problems with ‘random’ bugs - as though my Membership
database was 'sharing' information between users and applications rather than
keeping it separate.


I have now come across this article. Is what it is saying about Membership
being a singleton true?


---------------------------------------------------------------------------------
The Membership and Role classes use the singleton design pattern. I did not
instantiate either one in my code to access their ApplicationName properties,
I just used the instance that is automatically created for me. All
applications running on the same web server share the same instances of these
classes, and when one application changes a property, all applications are
affected. How can different applications use separate roles and users without
stepping on each other then?

If your applications are big enough to each have their own web server - or
web farm - there is no problem. You can set the application names in
machine.config and not worry about it. They can share a centralized
membership services database without interfering with each other. You could
set up separate databases to support membership services for each
application, at the loss of some centralization. You could also just use the
stored procedures directly, rather than accessing them through the Membership
and Role methods. This approach lets you set the application name directly,
without reference to the properties.

http://microsoft.apress.com/feature/59/membership-information-and-multiple-applications

 

[Cowboy \(Gregory A. Beamer\)]

Asp.Net v2.0
I have created a web application and I am using it from a single website
and
database. The web application has different 'portals' - each independent
and
I am using the Membership & Roles ApplicationName to separate out my
different groups of users within the membership database.

I had been having problems with 'random' bugs - as though my Membership
database was 'sharing' information between users and applications rather
than
keeping it separate.


I have now come across this article. Is what it is saying about
Membership
being a singleton true?

No, it is absolute crap. Static methods are not the same as a Singleton.

Even if it were true that Roles are shared amongst all applications in the
database (it isn't), that would not be a Singleton pattern either.

This is the table design for the aspnet_Roles table:

/****** Object: Table [dbo].[aspnet_Roles] Script Date: 11/28/2007 15:05:17
******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TABLE [dbo].[aspnet_Roles](

[ApplicationId] [uniqueidentifier] NOT NULL,

[RoleId] [uniqueidentifier] NOT NULL DEFAULT (newid()),

[RoleName] [nvarchar](256) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,

[LoweredRoleName] [nvarchar](256) COLLATE SQL_Latin1_General_CP1_CI_AS NOT
NULL,

[Description] [nvarchar](256) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,

PRIMARY KEY NONCLUSTERED

(

[RoleId] ASC

)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY]

GO

ALTER TABLE [dbo].[aspnet_Roles] WITH CHECK ADD FOREIGN KEY([ApplicationId])

REFERENCES [dbo].[aspnet_Applications] ([ApplicationId])

------------------

See the ApplicationID? That means a role is used once per application.
Without a custom membership provider, you will not share info.

Not sure of the Phantoms you are getting. Have you set the config files up
correctly for them to be different apps?

 

[ePrint]

Have you set the config files
Thats the problem. I am trying to run several applicationIDs from the same
web - so it has only one config file. I am setting ApplicationName (and so
applicationID) from within code.
It is under these circumstances that the static methids seem to be causing
me a problem. As I set the applicationName in one users thread it is also
changing the applicationName of all other users who are halfway through the
processing of their aspx pages.
This is the effect I am seeing. I am just having trouble believing that MS
ever designed it this way and was wondering if I was missing something simple.

Asp.Net v2.0
I have created a web application and I am using it from a single website
and
database. The web application has different 'portals' - each independent
and
I am using the Membership & Roles ApplicationName to separate out my
different groups of users within the membership database.

I had been having problems with 'random' bugs - as though my Membership
database was 'sharing' information between users and applications rather
than
keeping it separate.


I have now come across this article. Is what it is saying about
Membership
being a singleton true?

No, it is absolute crap. Static methods are not the same as a Singleton.

Even if it were true that Roles are shared amongst all applications in the
database (it isn't), that would not be a Singleton pattern either.

This is the table design for the aspnet_Roles table:

/****** Object: Table [dbo].[aspnet_Roles] Script Date: 11/28/2007 15:05:17
******/

SET ANSI_NULLS ON

GO

SET QUOTED_IDENTIFIER ON

GO

CREATE TABLE [dbo].[aspnet_Roles](

[ApplicationId] [uniqueidentifier] NOT NULL,

[RoleId] [uniqueidentifier] NOT NULL DEFAULT (newid()),

[RoleName] [nvarchar](256) COLLATE SQL_Latin1_General_CP1_CI_AS NOT NULL,

[LoweredRoleName] [nvarchar](256) COLLATE SQL_Latin1_General_CP1_CI_AS NOT
NULL,

[Description] [nvarchar](256) COLLATE SQL_Latin1_General_CP1_CI_AS NULL,

PRIMARY KEY NONCLUSTERED

(

[RoleId] ASC

)WITH (PAD_INDEX = OFF, IGNORE_DUP_KEY = OFF) ON [PRIMARY]

) ON [PRIMARY]

GO

ALTER TABLE [dbo].[aspnet_Roles] WITH CHECK ADD FOREIGN KEY([ApplicationId])

REFERENCES [dbo].[aspnet_Applications] ([ApplicationId])

------------------

See the ApplicationID? That means a role is used once per application.
Without a custom membership provider, you will not share info.

Not sure of the Phantoms you are getting. Have you set the config files up
correctly for them to be different apps?