Ruud Senden (Migrated from SEC-995) said:
AbstractSecurityInterceptor contains the following throws clause:
throw new IllegalArgumentException(
"No public invocations are allowed via this AbstractSecurityInterceptor. "
+ "This indicates a configuration error because the "
+ “AbstractSecurityInterceptor.rejectPublicInvocations property is set to ‘true’”);
Unfortunately, this exception doesn’t include any contextual information, making it hard to find out the exact problem. For example, for the MethodSecurityInterceptor subclass it would be useful if this exception included the class and method name that were attempted to be called.
In our specific situation, a single MethodSecurityInterceptor is re-used for multiple Spring beans and is set to reject public invocations (the interceptor gets added automatically to beans defined via some custom namespace). This means that for each bean that is defined through this custom namespace, authorizations must be explicitly added to the single MethodSecurityInterceptor configuration. If somebody forgets this, the exception mentioned above is thrown, but it is hard to find out exactly for which bean the authorizations are missing.
Ruud Senden said:
As I just found out, even enabling debug logging doesn’t help to find out the cause of this error; maybe at the very least MethodSecurityInterceptor should also do some debug logging about the current MethodInvocation.
Luke Taylor said:
I’ve added the secured object information to the exception message, so the MethodInvocation (usually a Spring instance which should have a useful toString method) or FilterInvocation responsible should be logged.