Relax final method implementations on AbstractRememberMeServices

[okohub]

Expected Behavior

AbstractRememberMeServices implemented RememberMeServices methods with final modifier. This actually blocks overriding these methods. We can relax strictness on method implementations for further extensions.

Current Behavior

Any class that extends AbstractRememberMeServices can not override RememberMeServices methods.

Context

Is this behaviour necessary? I am not seeing any advantage for making these methods final, on an "abstract" service.

I can submit a PR for this.

[sjohnr]

Thanks for reaching out @okohub! The preferred approach in Spring Security would be to start with a closed implementation and open up the API only when needed. I can't speak to the specific design considerations of AbstractRememberMeServices but it appears that there are many methods that can be overridden.

For example, loginFail cannot be, but cancelCookie and onLoginFail can be, which are the only two methods called within the final method. Can you provide more context behind your use case and a specific method you feel should not be final?

[okohub]

@sjohnr hi,

We actually tried to create a new custom "RememberMeServices" implementation for some specific cases.

"AbstractRememberMeServices" is base class for "RememberMeServices" logic. Even with a new custom implementation, extending "AbstractRememberMeServices" class is inevitable, because main logic is embedded into abstract class.
(This is also another improvement context btw)

So here is the thing; hooking into "RememberMeServices" methods which are public interface methods, is prohibited because of final keyword on override.

Another point; if I want to delegate some methods to existing implementations (like PersistentTokenBasedRememberMeServices), I can't do this because of "AbstractRememberMeServices" limitations. Just implementing "RememberMeServices" is useless in this way, which I pointed above.

I think these public interface methods should not be implemented as final in abstract classes. This makes an ambiguity IMHO.

[sjohnr]

Hi @okohub!

Just implementing "RememberMeServices" is useless in this way, which I pointed above.

Can you implement RememberMeServices and delegate to two implementations, both PersistentTokenBasedRememberMeServices and a custom one that extends AbstractRememberMeServices?

Another option would be to extend PersistentTokenBasedRememberMeServices instead. All of the methods it overrides from AbstractRememberMeServices can be overridden by your class. Could this work for your use case?

[spring-projects-issues]

If you would like us to look at this issue, please provide the requested information. If the information is not provided within the next 7 days this issue will be closed.