Using User Security
Before activating User Security, use this section for planning who should be granted access rights to what. Go to the Places, Styles, and Invite List pages, print them, and use them as a checklist when compiling what rights to assign to whom. Refer to the Tools section for instructions.
|Allows Users to
|Create new places
|Create new styles
|Create invite lists
|Create new invite lists
|Set up, modify, and schedule surveys in a place.
|Analyze aggregate data in surveys in a place.
|Examine raw data
|View individual response data in surveys in a place.
|Lock and stage
|Lock and stage surveys in a place.
|Delegate assigning the right to create surveys,
analyze data, and examine raw data in a place.
|Use a style template
|Modify a style template
|Use an invitation list
|Modify an invitation list
Only ViewsFlash Administrator(s) can grant Access Rights. They do so in the pages listed in the table above, using options that are available only to Administrators. The Access Rights page grants the right to create places, styles and invite lists, The places, Styles and Invite Lists pages have an additional selection that opens an Access Rights page where the Access Rights of the items selected can be changed.
If ViewsFlash is used in a highly trusted, small group, use appsecurity=user,open. This lets everyone have access to all places; if any require special protection, the administrator can use Access Rights to limit who can create surveys, analyze results, or examine survey data. Before installing this parameter, the Administrator should get an idea from users as to which places require additional security. After restarting the application server with this parameter, the Administrator should go through every place and add appropriate Access Rights.
Most of the time, user security is installed using appsecurity=user,closed (closed is the default). When the application server is restarted with this parameter, nobody will be able to access any places; the application will be essentially locked down. Therefore, go through existing places in advance, and plan ahead to see what users and/or groups should be granted what rights in what places.
When a place is created, the user who creates it is assigned all rights, and the Administrator should restrict those rights if appropriate. Deleting a place requires the right to Create Surveys in that place.
Typically, a group of places belongs to a set of individuals. Create a role for them, and assign that role appropriate access rights in every place they use. If some of those places require more restrictive rights, such as allowing only certain individuals to analyze data, grant those rights to those individuals or roles only.
When using appsecurity=user,closed, all users are granted the right to Use the core styles that come preinstalled with the product, and nobody is granted the right to modify any styles. The right to modify styles is granted by the Administrator from the Styles page.
When a style is created, the user who creates it is granted the right to Use it and Modify it; the Administrator should change these rights if appropriate. Deleting a style requires the right to Modify it.
A style that has been created for a particular purpose is typically used in very few places by very few users; assign those users the right to Use that style and assign one or more of them the right to Modify that style.
When upgrading to User Security after surveys have already been created, any existing survey that uses a style is automatically granted the right to use that style, since otherwise existing surveys would stop working!
When using appsecurity=user,closed, no one is granted the right to modify any invite lists. However, any survey or place or survey that uses an invite list is granted the right to that list automatically.
When an invite list is created, the user who creates it is granted the right to Use it and Modify it; the Administrator should change these rights if appropriate. Deleting an invite list requires the right to Modify it.
An invite list that has been created for a particular purpose is typically used in very few places by very few users; assign those users the right to Use that list and assign one or more of them the right to Modify the list.
Visibility and Unauthorized entry
In the places, Styles, and Invite Lists pages, as well as any pull-down menus, the only entities listed are those that the logged in user has the right to Use or Modify. The Access Rights granted to each user, either explicitly or by membership in a role, provide that user with a private view of what is relevant to him in the ViewsFlash application, while other user's views are kept private. Even a malicious user who copies or sniffs an application URL will not be allowed to enter an unauthorized place or perform any operations he does not have appropriate Access Rights for. Such an attempt, depending on its severity, will be either denied with a Forbidden (403) HTTP return code or with a message denying the request.
The Access Rights button in the main menu opens the User Access Rights page which allows revoking user rights and granting the right to create places,styles and invite lists, and gives a complete listing of who has what access rights throughout the application.
The places, Styles, and Invite Lists pages have an "Access Rights of selected" option, which allows selecting several of the listed entities and changing their Access Rights. A second option, "Who has Access Rights", shows next to each entity the users and roles that have rights to it. The Styles and Invitation Lists pages also have a Where Used option which shows what places use which styles or lists.
The Administrator has the right to set all Access Rights throughout the application. The Administrator can also delegate the right to assign Access Rights in a place to someone else by simply filling out the Access Rights box in the Assign Access Rights page. The designated users can then decide who should have the right to create surveys, analyze data, and examine raw data in that place, and appropriate menu items become visible to those users. Only Administrators can delegate Security.
Next: User Access Rights