I'm currently developping a University portal that uses single sign on
between multiple applications, and I would like to store my users in one
application and share them with other applications while keeping the roles
unique per application. For our portal, all our users would go in an
application called "UniversityPortal", and roles would be created in each
course application. Here's an example illustrating our proposed structure.
Applications Roles
UniversityPortal Application (Administrators, Editors, ...)
Chemistry Application (Students, Teachers, ...)
Religion Application (Students, Teachers, ...)
Math Application (Students, Teachers, ...)
I've noticed that when I call SqlRoleProvider.AddUsersToRoles("francis",
Students") from within the Chemistry Application, and then from the Religion
Application new records get added to the Users table each with a unique user
ID. Why is this, and is there a way to prevent this duplication of user data?
Also does this mean if a user wants to change his password, does he have to
do it for every application? I would really appreciate any feedback or advice
that could help me out.
Cheers
FrancisAside from the fact that it's usually not a good idea to mix Chemistry with
Religion anyway, probably the cleanest was to handle this is to override the
SqlRoleProvider class with custom methods that accept an applicationID, and
pass this concept through to the stored procedures, which can be easily
modified.
Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com
"Francis Reed" wrote:
> Hi
> I'm currently developping a University portal that uses single sign on
> between multiple applications, and I would like to store my users in one
> application and share them with other applications while keeping the roles
> unique per application. For our portal, all our users would go in an
> application called "UniversityPortal", and roles would be created in each
> course application. Here's an example illustrating our proposed structure.
> Applications Roles
> UniversityPortal Application (Administrators, Editors, ...)
> Chemistry Application (Students, Teachers, ...)
> Religion Application (Students, Teachers, ...)
> Math Application (Students, Teachers, ...)
> I've noticed that when I call SqlRoleProvider.AddUsersToRoles("francis",
> Students") from within the Chemistry Application, and then from the Religion
> Application new records get added to the Users table each with a unique user
> ID. Why is this, and is there a way to prevent this duplication of user data?
> Also does this mean if a user wants to change his password, does he have to
> do it for every application? I would really appreciate any feedback or advice
> that could help me out.
> Cheers
> Francis
Hi Peter
That's a great idea which will work very well in my situation. I decided to
derived from the SqlRoleProvider as shown below.
public class EconcordiaSqlRoleProvider : SqlRoleProvider
{
public EconcordiaSqlRoleProvider () : base()
{
}
}
I have a quick question concerning the SqlRoleProvider. Where is the
SqlConnection, ConnectionString, or ConnectionStringName stored in the
SqlRoleProvider instance? I want to use that connection for my custom methods
which accept the applicationID. If you can help me out or give any advice, I
would really appreciate it.
Cheers
Francis
"Peter Bromberg [C# MVP]" wrote:
> Aside from the fact that it's usually not a good idea to mix Chemistry with
> Religion anyway, probably the cleanest was to handle this is to override the
> SqlRoleProvider class with custom methods that accept an applicationID, and
> pass this concept through to the stored procedures, which can be easily
> modified.
> Peter
> --
> Co-founder, Eggheadcafe.com developer portal:
> http://www.eggheadcafe.com
> UnBlog:
> http://petesbloggerama.blogspot.com
<!-- membership provider -->
<roleManager enabled="true" cacheRolesInCookie="true"
createPersistentCookie="true" >
<providers>
<remove name="DefaultRoleProvider" />
<add applicationName="/" connectionStringName="LocalSqlServer"
name="DefaultRoleProvider"
type="System.Web.Security.SqlRoleProvider" />
</providers>
</roleManager
-- the provider name and type would be replaced with your custom provider
name and namespace/class names.
Peter
--
Co-founder, Eggheadcafe.com developer portal:
http://www.eggheadcafe.com
UnBlog:
http://petesbloggerama.blogspot.com
"Francis Reed" wrote:
> Hi Peter
> That's a great idea which will work very well in my situation. I decided to
> derived from the SqlRoleProvider as shown below.
> public class EconcordiaSqlRoleProvider : SqlRoleProvider
> {
> public EconcordiaSqlRoleProvider () : base()
> {
> }
> }
> I have a quick question concerning the SqlRoleProvider. Where is the
> SqlConnection, ConnectionString, or ConnectionStringName stored in the
> SqlRoleProvider instance? I want to use that connection for my custom methods
> which accept the applicationID. If you can help me out or give any advice, I
> would really appreciate it.
> Cheers
> Francis
> "Peter Bromberg [C# MVP]" wrote:
> > Aside from the fact that it's usually not a good idea to mix Chemistry with
> > Religion anyway, probably the cleanest was to handle this is to override the
> > SqlRoleProvider class with custom methods that accept an applicationID, and
> > pass this concept through to the stored procedures, which can be easily
> > modified.
> > Peter
> > --
> > Co-founder, Eggheadcafe.com developer portal:
> > http://www.eggheadcafe.com
> > UnBlog:
> > http://petesbloggerama.blogspot.com
I have the following
<roleManager enabled="true">
<providers>
<clear />
<add
name="AspNetSqlRoleProvider"
type="EconcordiaSqlRoleProvider, Econcordia, Version=1.0.0.0,
Culture=neutral, PublicKeyToken=null"
connectionStringName="LocalSqlServer"
applicationName="/UniversityApplication"
/>
</providers>
</roleManager
which is working good in the web.config, but my question was more about the
c# SqlRoleProvider class members. I don't see a member that contains the
connectionString. Like in the following.
public class EconcordiaSqlRoleProvider : SqlRoleProvider
{
public EconcordiaSqlRoleProvider () : base()
{
}
public string[] myMethod()
{
SqlConnection c = new SqlConnection(this._connectionString);
...
}
}
Where this._connectionString is a member from the inherited SqlRoleProvider
class. Do I have to code the this._connectionString myself, or is it
inherited somehow from the SqlRoleProvider class?
Cheers
Francis
"Peter Bromberg [C# MVP]" wrote:
> <!-- membership provider -->
> <roleManager enabled="true" cacheRolesInCookie="true"
> createPersistentCookie="true" >
> <providers>
> <remove name="DefaultRoleProvider" />
> <add applicationName="/" connectionStringName="LocalSqlServer"
> name="DefaultRoleProvider"
> type="System.Web.Security.SqlRoleProvider" />
> </providers>
> </roleManager>
> -- the provider name and type would be replaced with your custom provider
> name and namespace/class names.
> Peter
> --
> Co-founder, Eggheadcafe.com developer portal:
> http://www.eggheadcafe.com
> UnBlog:
> http://petesbloggerama.blogspot.com
>
>
> "Francis Reed" wrote:
> > Hi Peter
> > That's a great idea which will work very well in my situation. I decided to
> > derived from the SqlRoleProvider as shown below.
> > public class EconcordiaSqlRoleProvider : SqlRoleProvider
> > {
> > public EconcordiaSqlRoleProvider () : base()
> > {
> > }
> > }
> > I have a quick question concerning the SqlRoleProvider. Where is the
> > SqlConnection, ConnectionString, or ConnectionStringName stored in the
> > SqlRoleProvider instance? I want to use that connection for my custom methods
> > which accept the applicationID. If you can help me out or give any advice, I
> > would really appreciate it.
> > Cheers
> > Francis
> > "Peter Bromberg [C# MVP]" wrote:
> > > Aside from the fact that it's usually not a good idea to mix Chemistry with
> > > Religion anyway, probably the cleanest was to handle this is to override the
> > > SqlRoleProvider class with custom methods that accept an applicationID, and
> > > pass this concept through to the stored procedures, which can be easily
> > > modified.
> > > Peter
> > > > --
> > > Co-founder, Eggheadcafe.com developer portal:
> > > http://www.eggheadcafe.com
> > > UnBlog:
> > > http://petesbloggerama.blogspot.com
0 comments:
Post a Comment