At the end of the Identify phase, FPS knows the identity of the user. Some sites may wish to attempt to verify that the user is who he claims he is (this process is highly recommended). If this is desired, the verify forms (defined in the Verify section) will be used. If verification is not desired, the Verify section will be omitted from the APS configuration file.
This URL is the form used to request verification from the user. Its input fields must be defined as Optional or Required and it must have a Lookup setting so that FPS will know what to do with the input data.
Just like the Identify form, this could very simply be an HTML form. If the verification data is fixed, such as "Enter your Phone Number, Middle Name, and Account Number", then this will suffice. However, this is not terribly secure (but may be secure enough for your site).
Most sites want to read a challenge (question) of some sort from the user record and present it to the user. To this end, the Verify form can have initial data passed to it using the Initial setting.
Use the Initial setting to define what the page will need. FPS will create a cookie called NPSFPSData that will contain the initial data. Each field will be named as in the Initial setting, followed by an equals sign ("="), followed by the field's value, URL encoded. Multiple fields will be separated by ampersands. Thus, an Initial setting of:
Initial=FirstName=givenname;Question=SmPINQ
might create the cookie:
NPSFPSData=FirstName=Eric&Question=What%20is%20the%20name%20of%20your%20dog
You will have to use a server-side scripting language to read the cookie and parse it. Each scripting language has its own capabilities for doing so.
FPS does not use the cookie after setting it, so you are free to destroy it (FPS will destroy it automatically when the form is posted).
In order to "see" this cookie, your page must reside on the same logical Web Server as the FORGOT stub.
If special instructions (see initial) are used such that multiple values are to be passed for the same field (the Pick keyword), then the multiple values will be passed, each URL encoded, separated by pipes, as in:
Initial=Question=SmPINQ[Format=A,Pick=3] NPSFPSData= Question=100|200|203
If a Pick clause is used in special instructions, all of the answer fields must have the same element name and must appear in the same order as presented to the page. FPS tracks the questions and the order in which they should be presented and expects the answers back in the same sequence.
If there is not enough data to satisfy a Pick clause (because of a consume or restrict clause), no data will be returned to the page for that field. If the field is not marked as required (by placing an asterisk before its name in the Initial setting), the Verify form will be displayed, but there will be no value for the field. If the item is marked as required, the No Data URL page will be displayed.
It is especially important that the Verify page expire and prevent reviewing using the BACK button. Without taking these preventative measures, after a user has successfully used FPS, another user can press the BACK button to view the answers to the questions.
Another way to solve this problem is to make the input fields password fields, since the entered text is masked by asterisks and is not retained when the BACK button is pressed. However, this makes the page harder for users to use.
If the user fails to fill in all of the required fields or one or more of the fields contains an invalid character, FPS will redirect the user to this form. The URL will have a list of this missing or invalid fields appended to it, separated with ampersands ("&"). A question mark will be appended before the field names, if required.
The original fields values will be in a cookie called NPSFPSFields. This is useful in the event that you wish to repopulate the fields with original values. There is currently no way to tell if the fields in error were empty but required, or if they contained invalid data.
Usually, this is the same form as the Verify URL above. Typically, two additional pieces code are needed. First, near the top of the page, an error message should be displayed to the user:
<% If Request.ServerVariables("QUERY_STRING") <> "" Then %>
<font color="red">
Fields marked in red are either missing or invalid.
</font>
<% End If %>
Then any prompt associated with a field in error can be turned red.
<% ShowRed = (Instr(Problem, "&Answer&") > 0) If ShowRed Then %> <font color="red"> <% End If %> <b>Answer: </b> <% If ShowRed Then %> </font> <% End If %>
Of course, there are other ways to do this - this is only one way.
If a user answers the verification question(s) wrong, your site may decide to let the user try again. This is not recommended, but some sites wish to do so.
If your site still wishes to do this, supply a Retry URL setting to specify the form for FPS to use. This form must have the same fields as the Verify URL. Initial values are evaluated again, so random question selection (special instructions) may change.
Care should be taken when using this keyword to prevent an unlimited number of attempts (by a hacker). FPS puts no constraints on the number of retries that a user can make. smfpsLockoutCounter is only checked each time that the FPS process is started, not each time that a Verify form is displayed.
If the Retry URL is not specified and the user answers the question incorrectly, he will be transferred to the Invalid URL instead.
If the user answers the verification wrong, FPS will direct the user to this page. This is a terminal condition; the FPS process is terminated.
This should generally be static HTML referring the user to a customer support number, since they are unable to verify their identity. The user is not locked out of FPS.
The Initial setting (described below) specifies the initial field settings that the URL is to receive before processing. In the Initial setting, some values may be marked required. If so, and no value (or not enough values) can be determined, the user will be sent to this page instead. This is a terminal condition (FPS processing terminates - the user cannot use FPS).
In other words, this page is invoked when some data that is required from the user record is unavailable, either because it is blank, restricted, or consumed. This may be a temporary condition (because of some cases of consumed and the use of restrict) or it may be permanent and require that the user login and modify their own profile.
Typically, this is a page directing the user to a customer service representative and can be static HTML.
This setting specifies a page to send the user to if the user fails to answer the questions within the time period specified by the Timeout setting ("You did not answer quickly enough"). This reduces the ability of a hacker to socially engineer the answers to the verification question(s).
This is a terminal condition (FPS processing terminates - the user cannot use FPS at this time).
This could be a static HTML page. It could also be Forgot itself (or an intervening page with a message) so that the user can restart the FPS process.
The user is not locked out of FPS.
|
Copyright © 2014 CA.
All rights reserved.
|
|