• Choose a category
• All
• Classic-Fiction

By Root 5243 0

control also fires the ViewChanging and ViewChanged events. The former reaches the application when the control is going to change the view (such as when a user logs in). The latter event fires when the view has changed.

Creating a Login Template

The LoginView control lets you define two distinct templates to show to anonymous and logged-in users. You can use the following markup to give your pages a common layout and manage the template to show when the user is logged in:

To enjoy more features,

Basically, the LoginView control provides a more flexible, template-based programming interface to distinguish between logged-in and anonymous scenarios, as we did in the previous example by combining LoginStatus and LoginName.

Creating Role-Based Templates

The LoginView control also allows you to define blocks of user interface to display to all logged-in users who belong to a particular role. As mentioned, these templates take precedence over the template, if both apply.

...

...

The content of each block is displayed only to users whose role matches the value of the roles attribute. You can use this feature to create areas in a page whose contents are strictly role-specific. For the LoginView control to work fine, role management must be enabled, of course. The control uses the default provider.

The PasswordRecovery Control

The PasswordRecovery control is another server control that wraps a common piece of Web user interface in an out-of-the-box component. The control represents the form that enables a user to recover or reset a lost password. The user will receive the password through an e-mail message sent to the e-mail address associated with his or her account.

The control supports three views, depending on the user’s password recovery stage, as follows. The first view is where the user provides the user name and forces the control to query the membership provider for a corresponding membership user object. The second view is where the user must provide the answer to a predetermined question to obtain or reset the password. Finally, the third view is where the user is informed of the success of the operation.

Requirements for Password Retrieval

For the control to work properly, you must first ensure that the selected membership provider supports password retrieval. The password retrieval also requires the provider to define a MembershipUser object and implement the GetUser methods. Remember that the membership provider decides how to store passwords: clear text, hashed, or encrypted. Best practice, of course, is to only store hashed passwords.

If passwords are stored as hashed values, the control doesn’t work. Hash algorithms are not two-way algorithms. In other words, the hash mechanism is great at encrypting and comparing passwords, but it doesn’t retrieve the clear text. If you plan to use the PasswordRecovery control, you must ensure that the provider stores passwords as clear text or encrypted data.

Retrieving a Password

The PasswordRecovery control supports a child element named MailDefinition:

The element configures the e-mail message and indicates the sender as well as the format of the body (text or HTML), priority, subject, and carbon-copy (CC). For the same settings, you can also