WebPart and authorization

By default, all users can browse pages with WebPart, but to customize a page, the user must be authenticated. Therefore, to change the WebPartManager DisplayMode, this can only be done after the user logs on, or an error occurs. There are a number of ways to avoid this, such as using User.Identity.IsAuthenticated before changing DisplayMode.

The Authorization for WebPart customization is the same as other licensing practices, and is accomplished by modifying the web.config. For example, consider code listing 13-5, which shows WebPart elements, as well as personalization and authorization child elements. The authorization section has standard allow and deny elements, allowing users and roles to be selected to determine the current authorization. When you specify users and roles, you also need to specify verbs, either enterSharedScope or modifystate, or both. When set to enterSharedScope, indicates whether a user or role can enter a shared scope (that is, whether personalization information is shared among users), and when set to Modifystate, indicates whether the user or role can modify personalization information. In Listing 13-5, only users in the admin role are allowed to modify the personalization status of the page, and none of the other users have this permission.

Code listing 13-5 Configuring webpart Authorization

<webParts>

<personalization>

<authorization>

<allow roles= "Admin" verbs= "Modifystate"/>

<deny users= "*" verbs= "modifystate"/>

</authorization>

</personalization>

</webParts>

This can be used in conjunction with the authorization filter (Authorization filter) and custom code to indicate whether a WebPart is legitimate for the current user.