Feature Wiki
Tabs
Error handling and logging
1 Requirements
This suggestion aims to improve the error handling and logging of ILIAS. Right now, when there is an error, the corresponding error message can end up with the user. Apart from the fact that an error itself ruins the user experience, the display of error messages increase the problem because:
- the user does not know how to deal with an error (i.e. database errors)
- the user might be afraid that he broke something permanently (which isn't true in most cases)
Error handling for systemadministrators of ILIAS doesn't exist right now. In case of an error an admin has to have access to the server ILIAS is running on to check the necessary logfiles. This becomes inefficient quickly, as the systemadmin of ILIAS is not always systemadmin of the server.
To improve things I'd like to suggest the following:
- in case of an error, users should be redirected to a proper page containing instructions about what to do next (i.e. try agin, if the problem persist please contact an administrator)
- the actual error message must not be shown on this page, as it confuses users and possibly is a security risk (database error messages alone contain a lot of information hackers could use...)
- errors should be logged / saved to the database itself if possible
- error logs should be accessible via the ILIAS GUI, within the administration like: "Administration / System-Logs"
Related features:
2 Additional Information
- Idea / concept: Fabian Sesterhenn / sesterhenn@qualitus.de
- Funding: Required
- Development: Feature is to be developed by tbd
3 Discussion
JF 19 Aug 2013: We agree that the logging concepts could be improved. There are types of errors, that cannot be handled by ILIAS, since PHP aborts completely. These presentation of this type of fatal errors will ony be configurable in the php.ini file. The handling of all other errors can be improved. For this we would need a detailed technical concepts that covers topic like
- Error levels/error codes
- Modularization (information on which component triggered an error)
- Writing to different targets (especially file + database)
- Session information
- Access configuration (what information can be retrieved by whom?)
- Presentation in ILIAS
Marko Glaubitz, 31.03.2015: I like where this is going and I would like to propose a use case and workflow for handling errors on loadbalnced setups.
On ILIAS "clusters" using several webserver workers, find the right apache log file can be very tiresome.
Thus I propose:
- pursuing the idea of showing the user who encountered an error just a "reference code " or error code that they can then hand over to the sytem admins
- ILIAS should save an error report in the data directpry outside the web root, since this will definitely be independent from the webserver worker that "hosted" the error. I could image a very simple way of doing this: create a folder with the error code that the user received
- content of the folder: all info that can be acquired: timestamp, a stack trace, the context / ref_id that was involved, ...
- extension: there could be a very simple gui that lists all folders / errors that have occured so far and a simple selective download and deletion mechanism (e.g. something like the "export" of objects)
4 Implementation
...
Last edited: 2. Apr 2015, 12:13, Kunkel, Matthias [mkunkel]