Previous Topic: Change Password Interface (SmCPW)Next Topic: Query String Options


Change Password Forms

While APS provides a default form for doing so, custom forms can be written for password changes. They can be written in any language that can display a form. The form must POST to the SmCPW program (SmCPW.EXE on Windows) and may pass any or all command line arguments to it. If command line arguments are passed, the TARGET=<targetURL> should be passed, so that SmCPW knows where to send the user when the process is complete.

Note: Tests have shown that Netscape Communicator Version 4.70 may not support HTTP_REFERER correctly, so that HTML forms may not work correctly. No other browsers have yet been identified that have this same failing.

Prior to APS version 2.1, custom forms had to pass their query string to SmCPW during the posting process. Thus, such custom forms had to be written in a server-side scripting language, such as JSP or ASP, or as a CGI program. Since version 2.1, this is no longer required; custom forms can be written in HTML, if desired. If SmCPW receives a POST without any query string (the HTML form posts just to SmCPW), it will use its caller’s (referrer’s) query string.

SmCPW, when presented with an HTTP GET request, will generate an HTML form so that a user may enter password information.

SmCPW need not be used to produce the form. Instead, provide your own HTML for the form, if special processing is desired.

Any form that you desire can be used, as long as it provides three input fields: OldPassword, NewPassword and VerifyPassword. The last two must contain identical values. Set up your form to post its data to SmCPW or to whatever you have renamed that file.

An easy way to start is to run SmCPW through a browser and to select View Source from the browser’s menu. This action displays the raw HTML used by the form. You can save this HTML into a file and modify it as desired.

You can also run SmCPW from the command line and save its output. When run from the command line with no arguments (other than command line switches), SmCPW outputs the HTML to produce the form. From the command line, you can specify the -L and -C switches to make SmCPW produce the HTML in other languages; however, this approach requires that you have set up the proper translation files.

A single change password page may not be sufficient for your site. There aretwo types of password changes: Required and Optional. You can detect the difference using query string values (which is how SmCPW identifies the case) or you can use completely different forms. The different forms can be linked into your site separately through the APS configuration file and/or your home page (for voluntary password changes).

Additionally, password change warnings can invoke the page. You may wish tobuild an entirely separate page for this case that displays the number of days left to change the password (the number of days is available using the <DaysLeft> macro).

Customization without Custom Forms

SmCPW gets some of its text from the SmCPW.lang files located in the language directories on your Web Server. This includes not only the text to display for each prompt, but limited control of HTML tags as well.

You can modify these values in the lang file to perform some substantial customization of the default form without writing any web code.

Handling Errors

By default, SmCPW displays any error message (including content violations and communications errors) and forces the browser back to the form (using JavaScript). You can easily override this behavior, but it will require more work and more maintenance for your site. If you wish to use custom forms, no need exists to override this error handling, nor do you need to use a custom form to override this behavior.

All content and LDAP error messages are stored in files called APS.lang, located in the language directories on your Policy Server. Any of these messages can be modified using a standard text editor.

The password change confirmation and all communications error messages are located in the SmCPW.lang files stored in the language directories on your Web Server.

If any message to be displayed starts with http:, https: or /, SmCPW assumes that the message is a URL. After performing macro substitution (including replacing macros arriving in SmCPW’s query string), SmCPW redirects the user to the URL instead of displaying the message.

An easy test is to put the URL into the language file as desired, but put the text msg: in front of it. When you invoke the error, SmCPW displays the message with all macros replaced within the normal message box. Remove the msg: and SmCPW redirects the user to the page.

You can selectively redirect for some errors and use the standard messages for others.

If you are using internationalization as well, duplicate the URLs or specify different URLs for each supported language.