Deprecation of AbstractSecurityInterceptor

[jvmlet]

The deprecation note advises to use technology-specific interceptor (web, messaging or method), but AbstractSecurityInterceptor is technology-agnostic, which allows to implement spring security for other tech-stack, not covered by spring ecosystem, for example grpc security interceptor and seamlessly integrate spring security features (auth events ect).
Please keep this feature .
Thanks

[jzheaux]

Hi, @jvmlet. This is what AuthorizationManager is for, which you are free to implement for your gRPC needs. I imagine that such a GrpcAuthorizationManager would be quite similar to the interceptor you linked to.

What features specifically are you looking for in AbstractSecurityInterceptor that you feel should be ported over to AuthorizationManager or an abstract implementation of it?

[jvmlet]

The point is that GrpcAuthorizationManager is not actually grpc, it's the same authorization manager that drives the authorization process for every technology, nothing grcp-special. I want to be able to benefit from future spring security version (bug fixes, new features, improvement ect) just by upgrading the version and not by reimplementing the authorization process by myself - publishing security events, invoking voters, ect.
What IS special - it's technology binder: filter for servlets, interceptor for grpc, message listener for messaging middleware and so on.
The abstract security interceptor was like blue print for specific technology to derive from and plugin spring security, which is going to die soon.
Please resurrect it.