When FPS is first invoked by a user, this is the page that FPS will cause to be displayed. It is expected to present a form to the user. It must be a page that is not protected by SiteMinder. It need not be on the same directory as the Forgot stub, but must be on the same logical Web Server.
Technically, this could be a static page that merely presents a form. Each field on the page should be defined in the APS Configuration File in as either Optional or Required so that FPS will accept input.
The form must post to the Forgot CGI program.
In its simplest form:
<HTML> <HEAD> <TITLE> Please Identify Yourself </TITLE> </HEAD> <BODY> <b>Please Identify Yourself</b> <FORM method="post" action="/FPS/Forgot"> <b>First Name: </b> <INPUT type="text" name="FirstName"> <br> <b>Last Name: </b> <INPUT type="text" name="LastName"> <br> <INPUT type="submit" value="Submit"> <INPUT type="reset"> </FORM> </BODY> </HTML>
Note: On a Windows NT Web Server, the action attribute of the FORM tag must reference Forgot.exe.
That is all that is needed, bare bones. Additional features would include expiring the page (though it is not necessary in this case) and performing edits to ensure that no field is blank or contains invalid data when posting. Additional fields might also be desirable.
Additional code will be necessary if this form is also to be used as the Missing and Multiple URL forms.
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 URL. The URL will have a list of the missing or invalid fields appended to it, separated with ampersands ("&"). A question mark will be appended before the field names, if required.
There is currently no way to tell if the fields in error were empty but required, or if they contained invalid data.
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.
Usually, this is the same form as the URL (see URL). Typically, two additional pieces of 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, "&FirstName&") > 0) If ShowRed Then %> <font color="red"> <% End If %> <b>First Name: </b> <% If ShowRed Then %> </font> <% End If %>
Of course, there are other ways to do this - this is only one way.
If the user filled out the form presented by the URL, but multiple users were found matching the input criteria, this page is displayed. Depending upon your site, one of two cases may be in effect, in which case, this form must handle the correct case.
First, if the required fields on the URL must absolutely define a single user, then you have a data or login error in your flow and this page must handle the error case. In this case, this page should be just a static HTML page reporting the (internal) error and referring the user to your customer support line.
If, on the other hand, your identify form has optional fields on it that can be used to further refine the user search, this page might just request further information. For example, if your identification form requires first name and last name, but mail is optional, there may be more than one "Bill Smith" on file. This page could then request that one or more of the optional fields be supplied to further refine the search.
Typically, a site will use the same URL for this page as for basic identification, with the additional code:
<% If UCase(Request.ServerVariables("QUERY_STRING"))
= "MOREDATA" Then %>
<font color="red">
We are unable to uniquely identify you.
Please supply more information.
</font>
<% End If %>
Of course, this code would have to be ELSE'd with the equivalent code in Missing URL (see Missing URL) if the same page were to be used for both.
If no user matches the input criteria, this page will be presented to the user. This is a terminating case (the FPS process is done, since no user can be identified).
If not supplied, the value of Missing URL is used, with ?NotFound appended.
This should generally be static HTML referring the user to a customer support number.
If the user is properly identified, but it turns out that the user is disabled (due to an APS disabled group only), the user will be redirected to this page. This is a terminating case, since the FPS process cannot continue.
Note that this case is different, but related to, the Lockout case. Lockout may also cause the user to become disabled (using the Lockout Group DN setting). The first time this occurs (when the user is originally locked out), the user will be sent to the Lockout URL. If the user attempts to use FPS again, they will be sent to this page instead of the Lockout URL, since the user is disabled.
This should generally be static HTML referring the user to a customer support number. Administrator intervention will be required, since the user account will have to be enabled.
If a user attempts to use FPS too soon after he has already recovered a password (based on the Max Success Frequency setting), the user will be sent to this page.
This case is detected using smfpsLog.
This should generally be static HTML referring the user to a customer support number. The user cannot use FPS until the requisite time has elapsed.
A customer service application could delete information contained in smfpsLog to make FPS available again, but this would be counter-productive. The user needs to call the Help Desk to recover the password; the administrator there can reset the password. There is no need to delete logged information; to do so would be deleting auditing information.
If a user attempts to use FPS too soon after any attempt to recover a password (based on the Max Attempts Frequency setting), the user will be sent to this page.
This case is detected using smfpsLog.
This should generally be static HTML referring the user to a customer support number. The user cannot use FPS until the requisite time has elapsed.
A customer service application could delete information contained in smfpsLog to make FPS available again, but this would be counter-productive. The user needs to call the Help Desk to recover the password; the administrator there can reset the password. There is no need to delete logged information; to do so would be deleting auditing information.
If the user is locked out due to the Lockout Count, the user will be redirected to this page. The user will always be redirected to this page the first time that the count is reached. Further attempts to use FPS will also redirect the user to this page unless the Lockout Group DN specifies a disabled group, in which case the user will be considered disabled and will be redirected to the Disabled URL on subsequent attempts.
This case is detected using smfpaLockoutCounter.
This should generally be static HTML referring the user to a customer support number. The user cannot use FPS until smfpaLockoutCounter has been cleared.
|
Copyright © 2014 CA.
All rights reserved.
|
|