Hi Jeffery, hi Thomas, I think it´s worth discussing that and I support the annotation approach. Having annotated security constraints in actions may be indeed a neat and flexible way to go. I think the role annotation pretty useful and with non dynamic groups the groups annonation as well, but which is of lesser use in my case.
If integrated as a valve, it may be before ExecutePageValve? The one point I want to bring in is, that I am still on top of Turbine with Jetspeed-1 Framework, which has its own security model ***. As a result I am using isAuthorized check only in JSON context (JSONSecureScreen). This just means, that I am following the discussion and will throw in comments (or even changes ;-) .. Best regards, Georg *** Cft. chapter Registry Access Control, https://portals.apache.org/jetspeed-1/security.html configured in xml files (*.xreg files). Further reading https://portals.apache.org/jetspeed-1/registry.html. Jetspeed-1 additionally binds in this way actions and templates (by default) and other stuff. Jetspeed-1 had another target (portlets) and was later adopted by Jetspeed-2, but its security framework is well designed in the core IMO. To get an overview and to better understand the mechanism, cft. https://portals.apache.org/jetspeed-2/j1-migration.html. --------------------------------------------------------------------- To unsubscribe, e-mail: [email protected] For additional commands, e-mail: [email protected]
