| Summary | Allow custom error messages from pre/post auth hooks |
| Queue | Horde Base |
| Queue Version | 3.0.3 |
| Type | Enhancement |
| State | Resolved |
| Priority | 1. Low |
| Owners | Horde Developers (at) |
| Requester | eli (at) experthost (dot) com |
| Created | 3/25/05 (7764 days ago) |
| Due | |
| Updated | 5/30/05 (7698 days ago) |
| Assigned | 3/25/05 (7764 days ago) |
| Resolved | 5/30/05 (7698 days ago) |
| Milestone | |
| Patch | No |
State ⇒ Resolved
New Attachment: nicer[1].patch
where I forgot to call it like "_getAuthError()".
Fixed patch attached.
New Attachment: nicer.patch
get the current error type and return it if any (false otherwise -
maybe NULL might be better since you return a string type rather than
an integer type).
Word of caution - I have noticed that IE does not like more than 165
characters in a URL when handing a Refresh: header - thus there is a
good chance that using this patch will cause IMP to hang on
redirect.php rather than properly display the custom error message.
This doesn't happen in FireFox though.
State ⇒ Assigned
the use of the AUTH_REASON_MESSAGE error message via
Auth::_setAuthError(). Any other type will yeild the default message.
This is for a reason since it would make sense that
AUTH_REASON_MESSAGE be allowed, yet all others not since they are more
generic internal error messages.
Priority ⇒ 1. Low
Type ⇒ Enhancement
Summary ⇒ Allow custom error messages from pre/post auth hooks
Queue ⇒ Horde Base
New Attachment: custom_errors.patch
State ⇒ New
_horde_hook_postauthenticate), it is impossible to specify a custom
error message to be displayed to the user for login failures. This is
because the true/false return of the hook is used to simply generate
the generic login failure error message.
It would be nice to be able to specify a custom error message for all
hooks, and the attached patch allows for such a feature in at least
the pre/post auth hooks.
However, I would highly recommend the patch be used simply as an idea
- it generates low level warning messages sometimes when the
$GLOBALS['__autherror'] array does not exist (querying a non-existant
key name), and also hard codes the $GLOBALS['__autherror'] array in a
place where an abstraction function to access such info should really
be used.
Eli.