I have some legacy code I’m trying to bring up to snuff as I move it over into the CB framework. It contains security code scattered throughout the model functions (not just at the beginning). Mostly it’s like this:
Do other thing
I noticed Luis put a comment at the very bottom of the wirebox aop wiki page that indicates intra-function join points are not currently supported. I’m cool with that, but want to know the best way to then handle the code. If I’ve got domain logic that branches based on permissions the authenticated user has/doesn’t have, I’m thinking perhaps a facade to the user or a facade to the session is in order (to allow for encapsulation and unit testing/mocking).
I could also do the security checks in the handler and simply pass in values to the service model, but that seems clunky and like it would make the code a lot more bloated with plumbing just to transport the security info from one place to another. I’d rather inject a reference to the user and do the checks in the model, especially since the domain logic branches on it - seems like that’s a good indicator it’s a model concern rather than an application-logic/handler concern (those seem like the pre advice handlers are perfect for).
I know there’s a SessionStorage plugin, but I’m not sure how I’d persist the object I’m currently putting direction in the session (see above) and then have that user object injected into my models so they can do their security checks.