...
Expand | |||||||||
---|---|---|---|---|---|---|---|---|---|
| |||||||||
The first user interface layer of the flow is actually HTTP Basic authentication; if a header with credentials is supplied, the credentials are tested immediately with no prompting. If that step fails, or no credentials are supplied, then a view is rendered unless the request is for passive authentication or part of a non-browser profile. Views are handled by Spring Web Flow, so support various technologies, but Velocity and JSP are supported by default and the examples are all based on Velocity.
Example Velocity User InterfaceThe example Velocity templates views/login.vm and views/login-error.vm illustrate generally how to populate the form, and how to detect and respond to error conditions. Internationalization is performed through the use of Spring message properties (which can be overridden via the top-level messages folder). Information on Spring internationalization is near the end of this section of the Spring documentation. When rendering Velocity views, several variables are available to aid per-relying party customization. Spring form generation macros such as #springMessage and #springMessageText are available to Velocity templates. You can freely comment out or remove the "Do Not Cache" support of course, or use Javascript to automate it for certain address ranges. Error Handling 5.1
By default, a Java class is supplied and installed that implements a standard form of “analysis” of the state of the request to produce a plausible error message to display to the user. This is suitable for routine cases, and is called by the default login view template via the standard variable “errorMessageFunction”. The idp.authn.Password.errorMessageFunction property can be set to a custom bean definition of type Function<ProfileRequestContext,String> to do their own error handling, including via scripting, etc. Older/Advanced Error Handling ExampleThe error message classification feature allows error messages to be mapped into grouped "classes" of errors that can be used in the view to report the results of a failed login. The main value of this feature is in supporting chains of multiple validators because the system will accumulate all of the classified errors that occur so that a precedence of error types can be applied to decide what to report to the user. A working example of this dating back to the older view-centric model: views/login-error.vm
JSP User InterfaceThe use of JSP is not advised, but is supported. To do so, views/login.vm must be removed or renamed and the IdP restarted, or it will take precedence. Views in JSP should be created in edit-webapp/WEB-INF/jsp (and the warfile should be recreated with bin/build.sh or bin/build.bat and the container restarted). The old V2 Taglibs are supported for JSP for now, but we have plans to deprecate them in the future. |
...