Proper handling of Ajax exceptions

[msimkunas]

Unhandled exceptions in Ajax handlers are currently relayed back to the user. Since they can potentially contain sensitive details about the system, such as absolute file paths, these exceptions should be properly masked.

Depends on wintercms/storm#160.

[bennothommo]

@msimkunas should this perhaps only occur when in production mode?

[msimkunas]

@msimkunas should this perhaps only occur when in production mode?

I don't see much benefit in handling these cases differently. The actual error will be logged regardless.

[msimkunas]

I think it makes sense to handle debug/prod mode differently when it comes to regular error handling because in those cases the developer is presented with a detailed stack trace and debugging info when in debug mode.

This case, however, is different. We're not showing any kind of detailed debugging info, such as a stack trace, inside the client side error alert so the developer will be forced regardless to go through the logs manually. Showing just the exception message isn't really all that helpful to a developer so I would suggest to not differentiate between dev modes in this particular case.

[bennothommo]

@msimkunas this may have an effect on client-side error reporting. Immediately, I can think this might affect the Debugbar plugin, because it has some special handling for exceptions thrown in an AJAX call but might not necessarily be able to handle linked/previous exceptions (it also has some special handling for AjaxException throws themselves, but I don't think they're affected by your changes).

If I'm wrong and the Debugbar handles it fine, I'm happy for this PR to proceed.

[msimkunas]

@bennothommo I've discussed this with @LukeTowers and he suggested throwing an AjaxException and logging the actual exception with trace_log(). This way, the supperfluous AjaxException which is only intended for the end user will not be logged and the debugbar plugin wouldn't have to handle nested exceptions.

I haven't yet tested this but I'll give it a go soon

[bennothommo]

@msimkunas sounds good to me. :)

[LukeTowers]

I didn't think of the debugbar plugin, that would be a good point.

[LukeTowers]

@msimkunas were you able to take a stab at this?

[msimkunas]

@LukeTowers Not yet but I'll try to after the holidays

[github-actions]

This pull request will be closed and archived in 3 days, as there has been no activity in this pull request for the last 6 months.
If you intend to continue working on this pull request, please respond within 3 days.
If this pull request is critical for your business, please reach out to us at [email protected].

[LukeTowers]

@msimkunas are you still interested in making the necessary modifications to get this merged?

[LukeTowers]

Also should we add this handling logic to the backend controller base class as well?

[msimkunas]

@LukeTowers I’m sorry but my plans have changed and I’m no longer working on this. Maybe someone else can pick up the mantle…