Example B-3 shows the definition of AspNetLoginControl
.
AspNetLoginControl
derives from LoginControl
, and in its overriding of GetUserManager()
it returns the AspNetUserManager
implementation of IUserManager
, which uses the ASP.NET providers directly (see Figure B-4).
AspNetUserManager
is capable of using any valid ASP.NET 2.0 provider (hence its name). To use AspNetLoginControl
, you will need to add to the application’s configuration file the same values you would have placed in a web application configuration file, indicating which provider to choose as well as any provider-specific values and settings.
For example, to use the SQL Server provider (which is the default provider), add the settings shown in Example B-4 to the application configuration file. The connection string value shown in Figure B-4 is used to connect to the aspnetdb database on the local machine after default installation. Note the use of the enabled
attribute of the roleManager
tag to enable authorization.
Example B-4. Settings for AspNetLoginControl
<?xml version="1.0"?> <configuration> <system.web> <roleManager enabled="true"/> </system.web> <connectionStrings> <remove name="LocalSqlServer"/> <add name="LocalSqlServer" connectionString=" data source=(local);Integrated Security=SSPI; Initial Catalog=aspnetdb"/> </connectionStrings> </configuration>
AspNetUserManager
contains as member variables instances of the ASP.NET membership and role providers. All the functionality of IUserManager
is accomplished by delegating to the ASP.NET providers (see Example B-5).
Example B-5. The AspNetUserManager class
class AspNetUserManager : IUserManager { public bool Authenticate(string applicationName,string userName,string password) { Membership.ApplicationName = applicationName; return Membership.ValidateUser(userName,password); } public bool IsInRole(string applicationName,string userName,string role) { Roles.ApplicationName = applicationName; return Roles.IsUserInRole(userName,role); } public string[] GetRoles(string applicationName,string userName) { Roles.ApplicationName = applicationName; return Roles.GetRolesForUser(userName); } }
To implement Authenticate
, AspNetUserManager
calls the ValidateUser()
method of Membership
. To implement IsInRole
and GetRoles
, AspNetUserManager
calls the IsUserInRole()
and GetRolesForUser()
methods of Roles
.
AspNetLoginControl
works well, and you can certainly use it. However, it does have one important shortcoming you should be aware of. The ASP.NET providers were designed to be used on the server, and they require a few nontrivial permissions: unmanaged code access permission, unrestricted SQL Client access permission, and minimal ASP.NET Hosting permission. Typically, server-side applications run in an elevated trust environment (see Chapter 12 for a recommended server-side policy), potentially even full-trust, and will have no problem obtaining those permissions and executing properly.
AspNetLoginControl,
on the other hand, is going to be used by Windows Forms applications. It is quite likely that such applications will be executing in a partial-trust environment, perhaps as ClickOnce applications. The client environment may very well not grant the applications using AspNetLoginControl
the permissions they require to operate.
Table B-1 lists the permissions required for AspNetLoginControl
and who demands them. These permissions are the product of both the control itself and the components it uses: CustomPrincipal
and AspNetUserManager
.
Table B-1. Security permissions required by AspNetLoginControl
Permission type |
Specific permission value |
Demanded by |
---|---|---|
Security |
Execution |
Any managed application, in order to run |
Security |
Unmanaged code access |
The ASP.NET providers |
ASP.NET Hosting |
Minimal |
The ASP.NET providers |
SQL Client |
Unrestricted |
The ASP.NET providers, for accessing the database |
Reflection |
Unrestricted |
|
User Interface |
Safe sub-windows |
|
Security |
Control principal |
|
You have a number of options in choosing how to deal with these permission demands. You can grant full trust to the WinFormsEx.dll assembly and all its clients, but that is unadvised, as discussed in Chapter 12.
Alternately, using the .NET Configuration tool, you can grant most of these permissions both to the WinFormsEx.dll assembly and to every client application that wants to use it. You can also list these permissions in the ClickOnce application manifest. To ease the task of granting the permissions, the source files accompanying this book contain the WinFormsEx.xml file—it’s a custom permission set file that you can add to the .NET Configuration tool to grant the necessary permissions.
However, the best solution is to avoid the permissions demanded by the ASP.NET providers altogether and use a different implementation of IUserManager
—one that does not demand server-side permissions in a client environment. This option is presented next.