Creating Role-Based Templates
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 <loggedintemplate> template, if both apply.
The content of each <contenttemplate> 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
control is another server control that wraps a common piece of Web user
interface into 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.
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 in order 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
the control to work properly, you must first ensure that the selected
membership provider supports password retrieval. The password retrieval
also requires that the provider defines a MembershipUser object and implements the GetUser methods. Remember that the membership provider decides how to store passwords: clear text, hashed, or encrypted.
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 password as clear text or encrypted data.
Retrieving a Password
The PasswordRecovery control supports a child element named MailDefinition:
<maildefinition from="email@example.com" />
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 use a bunch of
equivalent properties on the associated Framework class and set values programmatically.
If the user who has lost the password has a question/answer pair defined, the PasswordRecovery
control changes its user interface to display the question and ask for
the answer before the password is retrieved and sent back. Figure 5 demonstrates the behavior of the control.
Figure 5. The PasswordRecovery control in action.
control first asks the user to provide the user name; next it retrieves
associated information and displays the security question, if any is
defined for the user. Finally, if an e-mail address is known, the
control sends a message with details, as in Figure 6. Bear in mind that you need to have proper e-mail settings in the web.config file, specifically in the <system.net> section, as below:
<network host="your.smtp.server" />
Figure 6. The e-mail message with password information.
The ChangePassword Control
control provides an out-of-the-box and virtually codeless solution that
enables end users to change their password to the site. The control
supplies a modifiable and customizable user interface and built-in
behaviors to retrieve the old password and save a new one:
<asp:ChangePassword ID="ChangePassword1" runat="server" />
The underlying API for password management is the same membership API we discussed earlier in this chapter.
control will work in scenarios where a user might or might not be
already authenticated. However, note that the User Name text box is
optional. If you choose not to display the user name and still permit
nonauthenticated users to change their password, the control will
the user is not authenticated but the User Name text box is displayed,
the user will be able to enter his or her user name, current password,
and new password at the same time.
The change of the password is performed using the ChangePassword method on the MembershipUser
object that represents the user making the attempt. Note that the
provider might pose an upper limit to the invalid attempts to change or
reset the password. If set, this limit affects the ChangePassword control. The control won’t work any longer once the limit has been exceeded.
the password has been successfully changed, the control can send—if
properly configured—a confirmation e-mail to the user, as shown in Figure 7.
Figure 7. The ChangePassword control in action.
The e-mail message is configured through the same <MailDefinition> element we saw earlier for the PasswordRecovery control.
The Continue button points the page with the control to a new destination URL to let users continue working. If you don’t set the ContinuePageDestinationUrl property, clicking the button simply refreshes the current page.
The CreateUserWizard Control
control is designed to provide a native functionality for creating and
configuring a new user using the membership API. The control offers a
basic behavior that the developer can extend to send a confirmation
e-mail to the new user and add steps to the wizard to collect
additional information, such as address, phone number, or perhaps roles.
Customization is supported in two ways: by customizing one of the default steps, and by adding more user-defined steps. Figure 8 shows the control in action in the Create User page of the WSAT tool.
Figure 8. The CreateUserWizard control in action within WSAT.
The difference between this control and the CreateUser
method on the membership provider is that the method just adds the user
name and password. The wizard provides a user interface and lets you
add more information in a single shot.
Resources to Write Attack-Resistant Code
can we design and code secure ASP.NET applications? First of all,
security is strictly related to the application’s usage, its
popularity, and the type of users who connect to it and work with it.
Paradoxically, a poorly secured application that isn’t attractive to
hackers can be perceived as being much more secure than a well-armored
application with just one loophole or two. Successful attacks are
possible through holes in the system-level and application-level
security apparatus. When it comes to security, don’t look for a magic
wand to do the job for you. Security is a state of mind, and insecurity
is often the result of loose coding styles, if not true programming
laziness. Never blindly trust anything regarding Web and ASP.NET
security. Always keep in mind that security for Web applications is
mostly about raising the bar higher and higher to make it hard for bad
guys to jump over.
following Patterns & Practices links can help you find great
information to fend off most common types of attacks and implement
effective input validation in ASP.NET applications: