Closed davidbarral closed 13 years ago
There is no problem, you can put your security class where you want. See samples-and-tests (logisima-play-cas-test) for an example !
Nope, It does not work :)
Maybe you are not getting my point. Let's see an example to clarify things.
First, in a custom module shared between many Play apps, a Security manager:
package controllers;
import controllers.modules.cas.Security;
public class CustomSecurity extends Security {
// Tons of shared code
public static boolean check(String profile) {
// Some checking!!
}
}
Second, in the current app:
package controllers;
public class CustomSecuritySpecialization extends CustomSecurity {
public static boolean check(String profile) {
// Override of the CustomSecurity check
}
}
So, which class is used as the Security Manager? Given the controllers.modules.cas.Security implementation (that I already posted) there is no guarantee that CustomSecuritySpecialization is selected as the SecurityManager because the algorithm is looking for classes assignables to the type Security and both of them are.
Do you see my point now?
Regards.
Hi,
Sorry for my misunderstanding !
You are trying to do something that is not supported in this module (neither on security module). You can't have more than one class that extends Security class
I suggest you to look at enhance method in the plugin class. I think this can be usefull for your needs (create a specific module for yours applications that enhanced the security class of your generic module).
Sincerely.
ok. Thanks.
The invoke method in controllers.modules.cas.Security (version 3.1 of the module) relies on the following code to detect the user Security class:
This algorithm only supports direct subclassing of the controllers.modules.cas.Security. That is a problem when some common behaviour is needed and code is refactored into an intermediate class. Current algorithm uses the first assignable class, however the getAssignableClasses does not return the deepest subclass first (actually I do not think that any order is guaranteed).
I cannot find any suitable methods in the Play API to avoid this problem. Maybe the solution is to be less "magical" and more explicit (maybe annotating the user Security class). Current code force the implementator of custom Security class to rely on composition instead of inheritance to especialize the code and that feels a bit ankward in this case.
Some ideas to share about this topic?