i am just curious
when i will need to use a custom AccessDecisionManager
i need some use cases from your experience guys, if anyone have used it before, thanks.
The canonical example given in the Spring Security docs is for customizing voter tallies, like if a particular voter should be weighted more heavily than others.
You could also customize behavior based on, say, properties of the secured object passed in to the decide method, for example, based on existing business logic. (That could also be handled by a custom voter, or other means, but if it's generic it might be easier to put it in a decision manager.)
IMO it's relatively unusual to need extensive customization at this level, but others may have additional insight.
You also need a custom AcceessDecisionManager if you have complex object for a granted authority, spring default only supports string for that.
Related
I am writing an app that writes some info specified by the user into some files specified by the user.
I want to use MVC pattern. I need some direction.
I can't figure out how to separate Logic from Ui.
I have some complex algorithms to perform on data(files provided by the user).
I think I need some module where these algs are stored and I just pass references to data, on which alg are performed. But MVC provides no such storage ~ or I don't know where to put it.
Please help me separate whatever is needed to be separated.
Should model store data and provide interface to access that data? Do I understand it right?
MAYBE I do not need MVC here?
So far I have come up with such a model:
Is it GOOD?
Where should algorithms go in MVC?
Put them in the Model.
MAYBE I do not need MVC here?
Almost no pattern is mandatory in any one scenario, but if you have a UI then MVC is probably a good idea.
I need to restrict method execution with specific parameters.
F.e. some seller can create bill for customer id=1 but can't for customer id=2.
Is it possible implement in spring security or I should make check in business logic code?
There are multiple options here:
You can use Spring Security ACL module to take into account actual domain object for your security restrictions. It is a good option when you have multiple security rules like this.
If you have only one security rule like this then using ACL module may be an overkill. In this case it will be better to make check in your business code. You have two options to call this code:
Call it declaratively using annotation. You will be able reuse this check more easy, but you lose control over raised exception (it will be default AccessDeniedException):
#PreAuthorize("hasRole('ROLE_AAA') and #billValidatorBean.validateForCustomer(#customerId)")
public createBill(Integer customerId, ...) {
Or implement it in corresponding method directly which gives you complete control over everything.
Choose your way depending on situation.
A few general questions to those who are well-versed in developing web-based applications.
Question 1:
How do you avoid the problem of "dependency carrying"? From what I understand, the first point of object retrieval should happen in your controller's action method. From there, you can use a variety of models, classes, services, and components that can require certain objects.
How do you avoid the need to pass an object to another just because an object it uses requires it? I'd like to avoid going to the database/cache to get the data again, but I also don't want to create functions that require a ton of parameters. Should the controller action be the place where you create every object that you'll eventually need for the request?
Question 2:
What data do you store in the session? My understanding is that you should generally only store things like user id, email address, name, and access permissions.
What if you have data that needs to be analyzed for every request when a user is logged in? Should you store the entire user object in the cache versus the session?
Question 3:
Do you place your data-retrieval methods in the model itself or in a separate object that gets the data and returns a model? What are the advantages to this approach?
Question 4:
If your site is driven by a user id, how do you unit test your code base? Is this why you should have all of your data-retrieval methods in a centralized place so you can override it in your unit tests?
Question 5:
Generally speaking, do you unit test your controllers? I have heard many say that it's a difficult and even a bad practice. What is your opinion of it? What exactly do you test within your controllers?
Any other tidbits of information that you'd like to share regarding best practices are welcome! I'm always willing to learn more.
How do you avoid the problem of "dependency carrying"?
Good object oriented design of a BaseController SuperClass can handle a lot of the heavy lifting of instantiating commonly used objects etc. Usage of Composite types to share data across calls is a not so uncommon practice. E.g. creating some Context Object unique to your application within the Controller to share information among processes isn't a terrible idea.
What data do you store in the session?
As few things as is humanly possible.
If there is some data intensive operation which requires a lot of overhead to process AND it's required quite often by the application, it is a suitable candidate for session storage. And yes, storage of information such as User Id and other personalization information is not a bad practice for session state. Generally though the usage of cookies is the preferred method for personalization. Always remember though to never, ever, trust the content of cookies e.g. properly validate what's read before trusting it.
Do you place your data-retrieval methods in the model itself or in a separate object that gets the data and returns a model?
I prefer to use the Repository pattern for my models. The model itself usually contains simple business rule validations etc while the Repository hits a Business Object for results and transformations/manipulations. There are a lot of Patterns and ORM tools out in the market and this is a heavily debated topic so it sometimes just comes down to familiarity with tools etc...
What are the advantages to this approach?
The advantage I see with the Repository Pattern is the dumber your models are, the easier they are to modify. If they are representatives of a Business Object (such as a web service or data table), changes to those underlying objects is sufficiently abstracted from the presentation logic that is my MVC application. If I implement all the logic to load the model within the model itself, I am kind of violating a separation of concerns pattern. Again though, this is all very subjective.
If your site is driven by a user id, how do you unit test your code base?
It is highly advised to use Dependency Injection whenever possible in code. Some IoC Containers take care of this rather efficiently and once understood greatly improve your overall architecture and design. That being said, the user context itself should be implemented via some form of known interface that can then be "mocked" in your application. You can then, in your test harness, mock any user you wish and all dependent objects won't know the difference because they will be simply looking at an interface.
Generally speaking, do you unit test your controllers?
Absolutely. Since controllers are expected to return known content-types, with the proper testing tools we can use practices to mock the HttpContext information, call the Action Method and view the results to see they match our expectations. Sometimes this results in looking only for HTTP status codes when the result is some massive HTML document, but in the cases of a JSON response we can readily see that the action method is returning all scenario's information as expected
What exactly do you test within your controllers?
Any and all publicly declared members of your controller should be tested thoroughly.
Long question, longer answer. Hope this helps anyone and please just take this all as my own opinion. A lot of these questions are religious debates and you're always safe just practicing proper Object Oriented Design, SOLID, Interface Programming, DRY etc...
Regarding dependency explosion, the book Dependency Injection in .NET (which is excellent) explains that too many dependencies reveals that your controller is taking on too much responsibility, i.e. is violating the single responsibility principle. Some of that responsibility should be abstracted behind aggregates that perform multiple operations.
Basically, your controller should be dumb. If it needs that many dependencies to do its job, it's doing too much! It should just take user input (e.g. URLs, query strings, or POST data) and pass along that data, in the appropriate format, to your service layer.
Example, drawn from the book
We start with an OrderService with dependencies on OrderRepository, IMessageService, IBillingSystem, IInventoryManagement, and ILocationService. It's not a controller, but the same principle applies.
We notice that ILocationService and IInventoryManagement are both really implementation details of an order fulfillment algorithm (use the location service to find the closest warehouse, then manage its inventory). So we abstract them into IOrderFulfillment, and a concrete implementation LocationOrderFulfillment that uses IInventoryManagement and ILocationService. This is cool, because we have hidden some details away from our OrderService and furthermore brought to light an important domain concept: order fulfillment. We could implement this domain concept in a non-location-based way now, without having to change OrderService, since it only depends on the interface.
Next we notice that IMessageService, IBillingSystem, and our new IOrderFulfillment abstractions are all really used in the same way: they are notified about the order. So we create an INotificationService, and make MessageNotification a concrete implementation of both INotificationService and IMessageService. Similarly for BillingNotification and OrderFulfillmentNotification.
Now here's the trick: we create a new CompositeNotificationService, which derives from INotificationService and delegates to various "child" INotificationService instances. The concrete instance we use to solve our original problem will delegate in particular to MessageNotification, BillingNotification, and OrderFulfillmentNotification. But if we wish to notify more systems, we don' have to go edit our controller: we just have to implement our particular CompositeNotificationService differently.
Our OrderService now depends only on OrderRepository and INotificationService, which is much more reasonable! It has two constructor parameters instead of 5, and most importantly, it takes on almost no responsibility for figuring out what to do.
If I need two modes in my application what design pattern would I use so I can prevent ugly conditional code? App is currently MVC, but I don't want conditional code in my controllers and don't want two controllers for each view unless I have to.
Any suggestions?
A different subclass for each implementation, with shared functionality either in a common superclass or using the Template Method pattern.
Perhaps the State Pattern?
Abstract Factory, or Proxy. Your controller would contain some kind of Factory or Proxy instance that is used to retrieve a "mode" and act on it accordingly.
It is difficult to say for sure without more information, but I would suggest the strategy pattern. You could use the same controller and just swap out the strategy object to produce the desired change in behavior.
Here is an article you may find useful:
http://www.javaworld.com/javaworld/jw-04-2002/jw-0426-designpatterns.html
take a look at JSR-168, java portlet and its reference implementation, it should be similar to what you are trying to achieve.
The appropriate place for such a decision is the controller of MVC. I would recommend you write it there first. If it really is repetitive, it may be straightforward to figure out how to clean it up: you can move the conditional logic into a base class, or depending on the language, may be able to handle it with some sort of filter. You may also be able to create some "factory" for the views, which understands the "mode" of your application. Architecturally, though, all this is in the controller.
You are right to not want it in the view. This would be pretty messy. You probably want two versions of the views, one for "view" and one for "edit".
In the end, this is what controllers are for. Good luck!
In CafeTownsend demo made with PureMVC there is a similar situation where there are two different views and two separate Mediators. You absolute don't need conditional code for that. I don't know what technology and programming language you are using, but in Flex it will be a ViewStack with the ListView and EditView as children:
Corresponding mediator is registered by demand when the view is created. You can check other implementations using previous link.
I am building an application using Spring MVC. I want to make certain changes to my Model for every Controller in the application. In particular, I want to insert certain extra data into the model which will be present for all pages of the application.
I could do this several ways: just add the data at the end of every Controller, use a subclass of Model that adds my extra data, use a subclass of ModelAndView that wraps my Model, use a subclass of VelocityView that wraps the Model before using it... I'm sure there are other options.
But I have an "elegance" constraint: I don't want to write code in each and every Controller, I want this behavior defined in one-and-only-one place. Ideally, it would be controlled by my IOC bean config file.
Does anyone have a recommendation of how to achieve this elegantly?
Aspects are a good approach, but Spring MVC makes it even easier -- you can define a HandlerInterceptor that will be called before or after every time a request is handled. In the HandlerInterceptor postHandle method (in your class that implements the HandlerInterceptor interface) you can add your data to the ModelAndView. You define which handlers should be intercepted in your config file.
You could take a look at using Aspects. Spring even has an AOP extension that you could use.
In brief an aspect would allow you to define code once that would then get "woven" into your classes either when you compile the classes or when they are loaded by the classloader. It's relatively advanced stuff and isn't the most intuitive thing for new programmers to pick up, but it's intended to solve exactly the problem you're referring to.
I might be wrong, but I suspect that you may have described your requirements incorrectly.
You seem to be saying 'I want certain data to be added to my model, for all controllers'.
I suspect that you mean 'I want certain data to be available for all views'.
If my suspicions are correct, then adding the data to you model is polluting your model and violating the single responsibility principle. This is especially true if the same data is to be added to several models. Be careful that you are not just using your model as a convenient 'carrier' of the data - where the data doesn't really have anything to do with the model.
Admittedly, I'm not completely familiar with the Spring MVC way of doing things, but a more detailed example of what you're trying to achieve may allow for a more informed discussion.