You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Introduce a new subclass of PersoniumCoreException and let it have the feature to have a logging different from the response.
Background
When access control mechanism with a Cell decides to shut the access,
based on the ACL settings and whatever, most of the code throw PersoniumCoreException with HTTP response status code 403 Forbidden and very simple message.
The message is intentionally made very simple for a security reason.
We do not want to give attackers information why the access is blocked.
Instead we need detailed logging on the server side so that app developers and Cell owners can know why the access was prohibited.
Howerver, currently the access block reasons are not sufficiently logged and many users are having difficulty finding the reason of access blockage.
We had had several attempts to improve this issue but never succeeded yet.
It is because the severity level of these exceptions are set at INFO as default and info level Exceptions does not leave detailed log at ExceptionMapper.
Effect of new Exception introduction
By introducing a special Exception class and let the access control related modules use the new exception, We can assure that the access denial reasons are logged as long as the new class is used.
The text was updated successfully, but these errors were encountered:
Overview
Introduce a new subclass of PersoniumCoreException and let it have the feature to have a logging different from the response.
Background
When access control mechanism with a Cell decides to shut the access,
based on the ACL settings and whatever, most of the code throw PersoniumCoreException with HTTP response status code 403 Forbidden and very simple message.
The message is intentionally made very simple for a security reason.
We do not want to give attackers information why the access is blocked.
Instead we need detailed logging on the server side so that app developers and Cell owners can know why the access was prohibited.
Howerver, currently the access block reasons are not sufficiently logged and many users are having difficulty finding the reason of access blockage.
We had had several attempts to improve this issue but never succeeded yet.
It is because the severity level of these exceptions are set at INFO as default and info level Exceptions does not leave detailed log at ExceptionMapper.
Effect of new Exception introduction
By introducing a special Exception class and let the access control related modules use the new exception, We can assure that the access denial reasons are logged as long as the new class is used.
The text was updated successfully, but these errors were encountered: