Whether CSLA.NET include custom membership and role management provider with WCF and Data Driven?

Whether CSLA.NET include custom membership and role management provider with WCF and Data Driven?

Old forum URL: forums.lhotka.net/forums/t/8734.aspx


zhihao posted on Sunday, March 28, 2010

Whether CSLA.NET include custom membership and role management provider with WCF and Data Driven?

RockfordLhotka replied on Sunday, March 28, 2010

There is no custom membership or role provider in CSLA .NET.

If you look at the PTWeb sample app (in ProjectTracker) or the CSLA .NET for Silverlight video series or the Core 3.8 video series, you will see examples where the normal membership and role providers provided by ASP.NET are used for authentication.

The only reason for creating a custom membership or role provider in CSLA .NET is if you wanted to use CSLA to create an application that created and edited user accounts and managed roles. If you want to use existing membership and role information there is no reason to create custom providers just for CSLA.

In at least one case I know that Magenic did create custom providers for a customer, because that customer did want to create and edit user information and manage roles through their app. And in fact they wanted it to work through the data portal like any other object, and so the "providers" were actually more sophisticated than normal providers because the implementation use all the cool features of CSLA .NET.

rsbaker0 replied on Sunday, March 28, 2010

What about the "IsInRoleProvider" support for substituting your own role membership test for the fixed role list test that CSLA provides? (Or does this not exactly address the OP's question).

RockfordLhotka replied on Sunday, March 28, 2010

I'm assuming the OP was about a custom ASP.NET membership provider. The IsInRoleProvider just lets you change how the IsInRole() method works, it doesn't enable the creation of a membership provider.

The trick with a CSLA membership provider is that the normal membership provider assumes a 2-tier model, where the provider code always has direct access to the database containing the membership information. But of course CSLA supports 3- and 4-tier deployments, so the objects might be running on a client without access to the database. Not that this is a real problem, but it is something a normal membership provider wouldn't need to worry about.

Copyright (c) Marimer LLC