Security and Authentication |
This section deals with various options available for anonymous and authenticated surveys.
Depending on the purpose of a questionnaire, knowing who participates and knowing that they only participate once can be relatively unimportant, as in the case of a simple popularity poll whose purpose is entertainment, to extremely important, as in a peer review survey that will influence compensation.
Depending on the purpose of a questionnaire, limiting participants to registered users may be desirable; other times, such as on a public site, it may be best to let people participate anonymously, without registering. The options on the Security and Authentication page handle all these situations.
Authentication Summary: the simplest authentication method to use is Cookie, which is the default. If there is no need for a Save button, the Servlet Session method is recommended. If a single sign-on system is in place, use Basic or J2EE Authentication. For single-page polls, it is possible to use No Authentication. In a portal, use Portal.
No Authentication
Choosing "Do not authenticate " in the Authentication Method radio
buttons means that no effort will be made to identify participants in any way.
When this method is chosen, it
is possible
to prevent
people
from participating twice by using Cookies and checking IP addresses. It is
important to be aware that these are low-security methods, but it is the
best that can be done without requiring additional authentication. This method
can only be used with single page surveys and cannot be used in portals.
Even though there is no way to ascertain the identity of any respondent in this case, some measures can be taken to prevent tampering with results through repeated responses. The two methods provided by ViewsFlash are Cookies and Duplicate IP detection. Unless there's a reason not to (such as a no-cookies site policy), it's best to use both methods to minimize ballot-stuffing. Note, however, that if a visitor comes to the site from a different machine, they will be able to respond one more time. And, of course, nothing prevents a visitor from telling all their friends to come to the site and vote for their candidate for Athlete of the Year!
Authentication
ViewsFlash works with all known forms of user authentication, ranging from
web server based authentication that requires user
ID and password, embedded browser credentials such as Windows integrated
authentication, J2EE managed security and single sign-on products,
or methods such as access cards or biometric information that record information
in proprietary browser headers or session attributes. It is also possible
to prepare
an
Invite
list of
user
IDs and
optional passwords just
for taking surveys and prompting the visitor for these before participating.
If some protocol is not supported out of the box, there is an Extensibility
option that can be used to write custom Java code to support it.
When authentication is used, assuring that people are who they say they are and preventing people from participating twice is as reliable as the authentication method used. Once a visitor is authenticated and participates in a survey, their User ID can be recorded in a "who has responded " table, separate from the collected data, to check that they do not participate again, but keeping their collected data anonymous. Or, by saving the User ID with the collected data, their responses are on record and the information gathered can be correlated with other information known about them. Cogix recommends informing visitors of whether they are participating anonymously of not.
The following matrix summarizes these settings:
| Survey type | Authentication method |
Duplicate detection |
Save User ID |
| Anonymous single page poll |
No authentication | Cookie, IP | No |
| Registration required, anonymous participation |
Any | Cookie, IP, User ID | No |
| Registration required, survey attributed to participant |
Any | Cookie, IP, User ID | Yes |
The Security page provides settings to select an Authentication method, whether to check for duplicates, and what to do about exceptional conditions, including unauthorized entry (no authentication information available), attempting to participate twice and attempting to participate before or after a survey is open.
Using multi-page surveys require using User Authentication. If there is no authentication method available, anonymous multi-page surveys are possible using the Servlet Session method described below.
Part A, choosing an authentication method. These radio buttons specify what method should be used to capture the user's identity, usually known as User ID or Login ID. This User ID will be used to uniquely identify the visitor for storing data between multiple survey pages and detecting duplicate responses (see above). It can also be stored with the data saved in the Save page.
Specific notes about certain authentication methods:
Basic HTTP or Application Server Authentication. 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.
IIS Windows Integrated Authentication. 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, and allows all users known to IIS to be automatically authenticated by ViewsFlash.
Servlet session. 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.
If a name is used, a servlet session Attribute, if present, or a Session Value by that name is used for the User ID. Technically, this value must be set by another application using HttpSession.setAttribute (Name,Value) or HttpSession.putValue(Name, Value) to store a user ID. For example, a servlet wrapped around the viewsflash servlet can use any means at its disposal to determine the User ID, such as validating a Digital ID against a relational database, or a single sign-on system.
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.
Form. This method presents the visitor with a login form asking them to enter a user ID and an optional password. These are validated against the User ID and password stored in the Invite List currently in use to invite people to a survey. To override 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.
Question. This method extracts the UserID from a question in the survey
form. The question is usually of type
hidden, and
it is
pre-populated using the ViewsFlash query string like this, for instance:
/ViewsFlash/servlet/viewsflash?cmd=page&userid=334433
Cookie. This method extracts the UserID from a cookie. Many custom authentication systems and some single sign-on systems record the authenticated user ID inside a cookie. If the cookie name is left blank, and the place 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.
Header. This method extracts the UserID from an HTTP header.
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; the recipient is anonymous, but because on subsequent visits the recipient has a new user ID, preventing duplicate entries is impossible when the portlet is displayed in a portal page that does not require logging in.
Role. This method is available when using J2EE Container Authentication (see Application Security). In addition to being authenticated, the visitor must be in the designated "Role". In Windows, roles are referred to as groups.
Survey 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 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.
Referer header must not be blank. If this box is checked, a blank "referer" HTTP header will cause the visitor to be considered not authenticated. If this option is not checked, a visitor with a blank HTTP header will always be authenticated regardless of the setting in the "referer must contain" option.
If using an invite list, allow people not on the list to take the survey anyway. When using an e-mail invite list, visitors are authenticated, and if a visitor is not on the invitee list, they are not authorized to take part in the survey. Checking this box allows authenticated visitors who are not on the invitee list to take the survey also.
Part B, recovering from unauthorized entry. These radio buttons specify what to do when Authentication has been chosen and a visitor submits a survey or poll form to ViewsFlash without being authenticated. The visitor can be redirected to a specific page, or a standard response page can be constructed. If neither one is specified, the visitor 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 survey or poll form.
2 Detecting duplicate responses
Part A, selecting a method. In order to assure the maximum accuracy possible, it is important to have methods for preventing visitors from responding more than once. Otherwise, a visitor who wants to unfairly influence the outcome of a survey, or who is simply destructive, can just push the Submit button repeatedly and throw off results.
In addition to standard server-based methods for access control, ViewsFlash provides its own methods to identify multiple responses, including using Cookies and checking for repeated responses from the same IP address. By default, all these methods are turned on to optimal values.
When "Throw a cookie" is checked, when a response is recorded and the response page is displayed, a cookie will be tossed to the visitor's browser, with the indicated name and expiration date, to record that the response has taken place. If the visitor attempts to respond again, the second and subsequent responses will not be recorded.
Similarly, 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.
The combination of both of the above methods, used simultaneously with the default values, assures the best protection possible against accidental and deliberate duplicate responses when authentication is not available.
When "Use User Authentication to prevent duplicate entries" 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. When using this option, Cookie duplication and IP checking will be turned off.
Revising Entries
When "Use User Authentication and allow participants to revise their entry"
is checked, ViewsFlash allows a visitor to enter data for the first time.
If a visitor returns to the entry form again, the visitor will be allowed
to revise the entry. This is useful when the data entered is a user profile,
for example. This feature requires running on a database, using a multiple-page
survey, and saving the data in its own table. 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. "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.