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.
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 using to the questionnaires using a hidden field in the form.
If a specific question is selected, the questionnaire must pre-populate that question using the ViewsFlash questionnaire's 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 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, sequential 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, When an attempt to participate is made without proper authentication. These radio buttons specify what to do when authentication fails for any reason. The respondent can be redirected to a specific page, or a standard response page can be constructed. If neither one is specified, the respondent will receive an empty page, usually displayed as an error by the browser. A default response page is provided: viewsflash/unauthorized.html, which will explain why authentication failed. If you create your own, start with a copy of this page to report more clearly what caused the authentication failure. This situation will most likely arise only while testing, since the web server and/or application server, when properly configured, will prevent an unauthenticated visitor from even seeing the questionnaire.
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 respond as if the response was not a duplicate, displaying poll results just like always. This method has the advantage that accidental, innocent duplicate responses will not disturb the visitor experience, while at the same time someone who is intentionally trying to influence results by responding repeatedly will probably think that they are being successful and will give up reasonably quickly. You can also choose to display a message, such as "You have responded already," or even take visitors to an entirely different page.
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.
If you specify a page to display, it can be a plain html page or a results template. The reference can be: a file name without a leading / and therefore relative to the ViewsFlash web server root, an absolute filename such as /dir/dir/filename, or an absolute URL (http://) reference to a page on another web server.
If you specify a page to redirect to, the visitor's browser will go there. If you enter *, the browser will return to the same page (the 'referer'). If you enter *?x=y, ?x=y will be appended to the URL of the referring page. This can be very useful with the Web Services API.
3 Saved Entries. In multi-page surveys, when the "Save" button is enabled, you can specify what will happen. You can redirect the visitor to a specific URL. When you redirect, if you specify a page to redirect to, the visitor's browser will go there. If you enter *, the browser will return to the same page (the 'referer'). If you enter *?x=y, ?x=y will be appended to the URL of the referring page. This can be very useful with the Web Services API. You can also use a specific response page by entering its full path in the file system, beginning with /. Additional information available in Multi-Page Surveys.
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 questions that must be answered have been answered by the visitor. If any of the questions have not, the three choices shown determine what to do with the entry. Note that a rejected entry will not count as a response for the purposes of preventing duplicate responses.
The first choice is to just tally any data that is available. (Note that not all four choices are always available).
The second choice specifies a page to redirect to. If you enter *, the browser will return to the same page (the 'referer'). If you enter *?x=y, ?x=y will be appended to the URL of the referring page. This can be very useful with the Web Services API.
The third choice is to ignore the answers and to display the results, using a Response Template page, into which the names of the unanswered questions are inserted, as in: "You have not answered the following questions: xxxx, xxxx, xxxx. Please answer them first." The viewsflash/vfincomplete.html template can be used or modified for this purpose. This page must be formatted in the same way as a Response Style Template, and must include the [/pendingerror] tag, which will be replaced by a listing of the names of the missing questions, separated by commas.
The fourth choice redisplays the poll or survey form, with the data entered by the visitor filling the form fields. An additional message is included to remind the visitor that certain fields are required, and a marker next to each unfilled question is displayed. This allows the form to be held up until the visitor completes all the required fields. The visitor only has to answer the questions that remain to be answered. It requires a Poll Template page; leave the field blank to use the place's template. On that template, it uses the [/statusmsg] to display the error text, [/dataerror] to display the error pointer, and [/origanswer] to display visitor's original answers. (See Style Template Tags). The default values for these cause "Please answer the questions marked X" to appear at the top of the survey form and X to appear to the left of each unanswered question.
5 Late submissions. It is possible that a visitor's survey form remains open in their browser beyond the survey closing time. This section specifies how to respond. You can choose to display the normal response page and add a message. You can also display results using a specific template.
You can also redirect the browser to a specific URL. If you specify a page to redirect to, the visitor's browser will go there. If you enter *, the browser will return to the same page (the 'referer'). If you enter *?x=y, ?x=y will be appended to the URL of the referring page. This can be very useful with the Web Services API.
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.