Reputation: 86774
I'm building a Tomcat/Java MVC Servlet app using Spring MVC and Spring Security, and have come upon what looks to me like an architectural inconsistency between the functionality of the Controller and the Authorization step.
In standard MVC a display Controller examines the request, builds the model representation of the business resource(s) involved, and specifies the view that is to render the output to the client.
In my use case the "business resource" being served is a "photo album" consisting of a configuration file (containing album title, copyright, etc) cached metadata (dimensions, thumbnails, access requirements, etc) and the actual images. Some Albums are private, requiring that the user be logged in and have a specific group membership. This part is well encapsulated in an Album
class and associated factory responsible for managing instances. Prior to adding security the Controller used the factory to find the requested Album
instance, and placed it into the Model for use by the View.
Then I added Spring Security to the mix. Since Authorization happens in the servlet filter chain (before the Controller is invoked) and Authorization needs access to the Album
object to make an access control decision, I am forced to locate/instantiate the Album
during the Authorization phase instead. This doesn't feel quite right but I can't see any other way to accomplish my goals without duplicating functionality.
Question: Is it a normal pattern in web applications for some of the model-building to get pushed back into the Authorization step, or have I missed something important? BTW, in order not to lookup/instantiate the model object twice I plan to put it into the HttpServletRequest
as an attribute for use by the Controller.
Upvotes: 1
Views: 86
Reputation: 86774
Since I got no answers I'm going to share my own insights.
I simply didn't understand the scope of Spring's declarative security model. If you have a set of resources which have a binary accessibility state (yes/no) based on the logged-in user, then Spring Security's model is appropriate. If you need finer-grained control (i.e. display a page but tailor its contents based on logged-in user), then you have to do your own filtering at page generation time.
Upvotes: 1