Security and Authentication |
Questionnaires, when more than one page long, require an ID for identification and authentication as the person filling it out moves from page to page. In some cases, such as a retirement plan survey, it is necessary to know the identity of the person who is filling out the questionnaire. In other cases, the questionnaire is not about the person who is filling it out, but rather about some event, such as a Help Desk request form. identified by a form number. Finally, there are times when no ID is required at all, such as anonymous popularity polls for entertainment.
Polls, also known as single page forms as designated on the General page, are the only kind of questionnaires that do not require authentication. All others require selecting one of the methods presented in this section.
Regardless of the authentication method used, anonymity can be preserved by choosing, in the Save page, to not record the ID of the person completing a questionnaire in the data set. It is also possible to restrict who participates using an Invite list.
1 Questionnaire Authentication
Part A - Specify what method to use to identify each questionnaire. The methods are categorized by where the questionnaire ID comes from.
When a questionnaire should be identified by the user's ID, choose one of these methods. All of them require the user to be logged in to the corporate network with their usual credentials, and all of them will user their User ID to identify the survey. Note, however, that anonymity can be preserved by choosing to NOT save the questionnaire ID in the questionnaire's Save page.
Basic. When this option is
chosen, the questionnaire is available at a special URL, namely http://..../servlet/vfauth?...
This special URL is protected by the application server, which requires the
respondent to authenticate.
(see Application Security).
This option
is used most often in intranets, allowing for single sign on.
Technically, this option retrieves the user ID using the getRemoteUser() method and is compatible with any authentication method that supports this standard J2EE protocol. See also Extensible Authentication for other authentication techniques supported.
Portal. This method is used in questionnaires that are presented in a Portal by the Cogix Survey portlet. The user ID of the currently logged is used.
If the user is not logged in, a unique random user ID is used and the respondent is anonymous because on subsequent visits the respondent has a new user ID, so preventing duplicate responses requires that the portlet be in a page that requires logging in.
IIS Windows Integrated Authentication. The user ID provided by IIS is used. This method expects an AUTH_TYPE header of NTLM, Negotiate, or Kerberos, and the user id in REMOTE_USER. This is how IIS normally operates.
Role. This method is identical to Basic, above, and in addition to being authenticated, the visitor must be in the designated J2EE role.
ViewsFlash is often deployed as part of a larger application, which is responsible for managing the IDs of its questionnaires. In a complex form application, the larger application may generate and manage Form IDs; in a heavily trafficked web site, the web server may create tokens that enforce third-party authentication and make them available to ViewsFlash. The common element is that ViewsFlash must look in its environment for information that identifies the questionnaire.
Cookie. This method extracts the ID from a cookie. Many custom authentication systems and some single sign-on systems record an authenticated ID in a cookie. A prefix and suffix that surround the ID can be specified to parse the cookie.
If the cookie name is left blank, and the Place where the questionnaire is located specifies concurrent surveys, a cookie named ViewsFlash will be used, and if that cookie is not present, a cookie will be sent to the browser with a unique random number that will identify that user's computer for all surveys. If the cookie name is left blank and the place specifies one survey at a time, a cookie with the name of the place, expiring when the current poll closes, will be used instead.
Session Attribute. When choosing this option, if the name is blank, the Session ID will identify each visitor while they complete a multi-page questionnaire. The Session ID is a random number created at random that identifies the visitor while they are sitting at their computer; it does not contain any traceable personal information, so this option allows visitors to participate anonymously. Note that questionnaires with too many items on a page that take a long time to complete are at risk of experiencing session timeouts and loss of data.
If an attribute name is used, the ID found there. Technically, this value must be set by another application using HttpSession.setAttribute (Name,Value) to store a user ID.
Entering the value CAPTCHA allows using this method with the ViewsFlash/start.jsp "Captcha" authentication form. Instead of directing respondents to /ViewsFlash/servlet/viewsflash?cmd=page&pollid=SSS!PPP, direct them to /ViewsFlash/start.jsp?cmd=page&pollid=SSS!PPP. A captcha login form will be displayed, asking them to enter the letters in the graphic. This is an excellent method of allowing anonymous surveys while preventing against robot attacks. The start.jsp page can be copied and customized as desired, and includes the source code for adapting the graphics if necessary.
Header. This method extracts the UserID from the designated HTTP header. The web server is responsible for setting the header.
Question. The ID is passed as a field in the questionnaire's form. The default option, "Use a generic field", assigns random, encrypted ID numbers to the questionnaires using a hidden field in the form.
If a specific question is selected, that question must be pre-populated
using the request query string. For example, if a question named "formid" is used, the URL is:
/ViewsFlash/servlet/viewsflash?cmd=page&pollid=xx!xx&formid=334433
The question is usually created as a ViewsFlash question of type hidden.
When a specific question is selected, ViewsFlash can assign numbers to the questionnaires by setting the prepopulated value to $ or $*. For example:
formid=$ assigns a sequential number, starting with 1.
formid=$* assigns random encrypted IDs.
Form. This method requires using an Invite List. The visitor is presented with a login form to enter an ID and an optional password. These are validated against entries in the Invite List currently
in use to invite people to a survey.
To customize the default login form, make a copy of ViewsFlash/surveylogin.html in the ViewsFlash directory, modify it, and save it in the applications' WEB-INF/classes, then enter then name of the modified file in the "Use login form" field, such as mysurveylogin.html.
None. This method can only be used with polls and single page questionnaires where, because they are only one page long, an ID is not needed to move from one page to the next.
If none of the authentication methods that refer to a specific ID are appropriate, use "Question" with a generic field. This method generates, automatically, unique ID numbers for each questionnaire, and passes the IDs from page to page in a hidden form field. It is the easiest and most reliable method for authenticating questionnaires when no better choice is available. The Question method, with a specific ID field, gives a little bit more control over the IDs, especially for creating URLs, because the ID is stored in a field that can be referred to like any other field.
For applications where the questionnaire is essentially a form, rather than a set of questions about the respondent, question authentication is also recommended.
For applications where ViewsFlash is being used as a component in a larger system, use a Session Attribute and have the host system set that attribute before displaying the VIewsFlash questionnaires.
These options are available always regardless of the authentication method selected above.
Questionnaire must use SSL. If this box is checked, the survey URL will begin with https://, and all data entered in the survey will be protected using Secure Sockets Layer technology. If a visitor attempts to take this survey at the same URL without https://, they will be considered not authenticated. To use a non-standard port for https, use the securesurveyport servlet parameter.
Referer header must not be blank. If this box is checked, the "referer" HTTP header must be non-blank, or else the questionnaire will be considered not authenticated. If this option is not checked, a blank HTTP header will always be authenticated regardless of the setting in the "referer must contain" option below.
Referer header must contain. If this box is checked, the "referer" HTTP header will be checked to make sure that it contains the exact string provided. If it doesn't, the visitor will be considered not authenticated.
When using invite lists, allow IDs that are not on the list. When using an e-mail invite list, questionnaires are authenticated usign the method selected above. If a questionnaire's ID is not on the invitee list, it is not rejected as not authenticated. Checking this box allows questionnaires that pass authentication when their IDs are not on the invitee list.
Part B - Recovering from unauthorized entry. These radio buttons specify what to do when authentication fails for any reason. A special response page is displayed. The default page is viewsflash/unauthorized.html. To specify a custom response page, use a Page Reference - see below. Alernatively, the visitor can be redirected to a specific page. See Redirecting below.
A page reference can be:
You can redirect in these ways:
2 How to handle multiple entries for the same questionnaire
Part A - Choose what is allowed.
For multiple page questionnaires, the following two options are shown:
| Allow one response only, which cannot be edited after completing it. | |||
| Allow one response only, and allow editing it after completing it. Leave both boxes unchecked to allow multiple responses with the same ID. |
|||
When "Allow one response only, which cannot be edited after completing it." is
checked, ViewsFlash will authenticate the user according to the selected method,
and use that unique User ID to detect attempts at a duplicate responses.
In some applications, such as entering a Help request form, it is appropriate to have the same user submit multiple instances of the form. Leaving both of these selections unchecked is appropriate for that case.
In others, such as surveys, it is best to have the respondent complete the form only once. Checking the first of these selections accomplishes that.
In others, such as submitting a request that can be revised after the form data is reviewed, check the second of these selections. When the respondent returns to the questionnaire with the same ID, it will be presented with all data already entered filled in, and the respondent can make changes to the data previously entered.
In voting and survey applications, it is usually to ascertain that only authorized users can participate. Using a single sign-on system and an Invite List together provides this certainty.
For polls and single page questionnaires, as selected in the General page, the following additional options are shown:
| Treat repeated submissions from the same IP address as duplicates, with the following exceptions: | |||
| After milliseconds, accept submissions from the same IP address. | |||
| Treat different Browser ID strings as different submissions | |||
| Throw a cookie | |||
When "Treat repeated voting from the same IP address as duplicates" is checked, ViewsFlash will check the IP address of the visitor's computer against the IP addresses of all visitors who have submitted entries in this poll in the indicated time, and reject the response as above if the IP address is already recorded. However, because many ISP's reuse IP addresses, particularly for dial-up connections, it's important to try to detect when different people are using the same IP address. This is done by checking the "Treat different Browser ID strings as different submissions" box, and by entering a time limitation on the check. Changing these values will result in more strict checking. For example, on an intranet, there is no reuse of IP addresses usually, and it would be best to leave the time limit blank and remove the check from the different browsers checkbox.
When "Throw a cookie" is checked, the ID selected by the authentication method, if any, is ignored, and instead, a cookie is maintained in the participant's browser, with a history of the questionnaires the respondent has filled out, and is used to detect an attempt to fill out the form repeatedly. This method is not as good as using the single sign on authentication methods and is recommended only as a last resort.
The combination of both of the above methods, used simultaneously with the default values, assures the best protection possible against accidental or deliberate duplicate responses when authentication is not available.
Revising Entries
When "Allow one response only, and allow editing it after completing it"
is checked, ViewsFlash allows a respondent to fill out the questionnaire normally the first time.
If a respondent returns to the questionnaire again with the same ID, the respondent will be allowed
to revise the entry. This is useful when the data entered is a user preferences profile or a services request form,
for example. This feature requires running on a database and using a multiple-page
questionnaire. If these conditions are not
met, this option will not be displayed. Note that
live tallies count only the first entry, but analytical tools such as Univariate
and Crosstabulation analysis count the modified entries.
Part B - acting against duplicate attempts
When an attempt at a duplicate response is detected, you can choose to redirect to an error page, or in the case of single question polls, respond as if the response was not a duplicate, displaying the response page just like always. You can also choose to display a message, such as "You have responded already".
The four radio buttons specify what to do when a duplicate submission attempt is detected. You can choose to respond normally, giving no indication that the attempt was detected as a duplicate and was ignored.
If you provide text to insert, such as "You have responded already," it will take the place of the [/statusmg] tag in the response template.
You can display a standard response page to display or customize it - see Page Reference. The default page is viewsflash/duplicate.html.
Alernatively, the visitor can be redirected to a specific page. See Redirecting above.
3 Saved Entries. In multi-page
surveys, when the "Save" button is enabled in the General page, you can specify what
will happen when it is pressed.
The visitor can be redirected to a specific page - see Redirecting above.
Alternatively, you can display a standard response page or customize it - see Page Reference above.
The default page is viewsflash/resume.html.
4 Incorrect entries. When a question requires an answer, as checked in the Define Question page, the submitted entry will be checked to make sure that all required questions have been answered. Other validation checks are carried out as well. When the "inline error messages" option in the General page is used, validation is done in the browser, but some kinds of checking are done by ViewsFlash on the server.
In that case, the questionnaire is redisplayed with the data entered by the respondent, an additional message reminds the resondent that certain fields need to be corrected, and a marker next to each affected question is displayed. The usual Form style is used, but you can specify a different Style (see Style Template Tags). The default values for these cause "Review marked questions X" to appear at the top of the questionnaire and X to appear to the left of each unanswered question.
5 Late entries. It is possible that a questionnaire is submitted after the questionnaire's closing time. You can choose to display the normal response page and add a message. You can also display a standard response page or customize it. see Page Reference above. The default plage is viewsflash.close.html.
You can also redirect the browser to a specific URL. See Redirecting above.
6 Data
review and modification. NOTE: this option requires that the Data Review and Modification API be enabled by the System Administrator. In multiple page surveys, these settings enable
reviewing a survey's data after it has been completed, as well as modifying
that data, using API commands.
The data needs to be saved in the database using the settings on the Save page, either in its own table or in the Normalized format in VWFDATA.
The options mean:
"No one", the default, disables this capability. "The visitor, right after completing it" allows redirecting
the visitor to a review page immediately after completing the survey (while their
browser session is still active). "The visitor, any time after completing it" allows
letting the visitor review or update his results any time after completing the
survey. These options only allow the user to review or modify the survey he completed.
However, when using User Security, the "Administrator
with access rights" option allows ViewsFlash administrators with the Examine
Data access right to review or modify anyone's data.