Where should I put on when to log the actions of the user, on Domain, or Presentation layer?
If Presentation Layer (Assuming MVP): After the presenter calls the interactor/usecase, it will call another usecase to add an activity/history log.
If Domain Layer: After the interactor/usecase itself does the action, it will save to the history/activity logs storage.
I'm confused if history/activity log is part of presentation layer as the text/action that will be log (eg string: User like this comment) looks like not needed on domain layer.
But I'm also confused if history logging is part of an application logic, which is Domain layer. Because if I'll put it on Domain layer, the log text format will be hard coded on usecase/interactor.
It depends what you want to achieve. If you just want to collect which UI elements and which parts of the UI are used by the users most often, adding the logging to the Presentation Layer might be sufficient.
If your focus is on logging which functionality is used by your users most often and how it is used then logging should be in the Domain Layer/Application Layer. In this case the decision which information is logged for each "activity" is part of the business rules.
You may want to use something like a Repository Pattern to keep the Domain Layer independent from the actual writing of the log.
Related
I am building an API where users and admins can interact with the same data, but with different needs.
A user can also have access to the admin panel, if he has the "admin" role.
Let's see for example we have a resource like Badges. A Badge is simply a reward when you achieve some actions into the app.
GET http://localhost/api/v1/badges
An authenticated user can call this endpoint and it returns the list of all badges, if they have it or not, with progress details.
GET http://localhost/api/v1/badges?user_id=2
with user_id parameter, we can see these details of another user (if he allows it).
But from the admin scope, I just need to see the list of all badges, without achievement details (CRUD operations).
So I have 2 options in mind:
Create "admin" endpoints: GET http://localhost/api/v1/admin/badges.
Adding custom header "X-App-Scope" to identify if I am in admin or user.
I don't like the second one because I think I will have so many if statements and behavior in the same endpoint, depending of the scope.
Because I have lots of use cases like this, I want to make sure my API architecture is good to handle user/admin needs.
Do you guys have any idea/example to manage stuff like this?
Thanks!
My personal preference is to separate admin API routes from user ones. i.e. having two routes
/api/v1/badges
/api/admin/v1/badges
You will have two unique documentation, one for each route, which makes it easier to maintain and understand
It will be easier to tell the difference between the user and the admin versions
There is no need extra code to check for request headers or url params.
It makes your middleware less complicated, especially if authentication and permissions are handled there.
It is more scalable for teams as there is only one kind of request and response format per API.
TL;DR: REST is designed in the expectation that you would use two different resources here.
The core problem is this: how would a general purpose component, like a browser, know that your special resource needs to have this custom header added?
In particular, consider the case where I send to you a copy of the URL for this resource, and nothing else. How are you to know to add the customer header to the request?
On the other hand, if you use different resources to share this information with each audience, everything just works.
The only way I found to stay as simple/clear as possible is to make multiple endpoints, for each use case:
GET http://localhost/api/v1/badges to get all badges in raw data
GET http://localhost/api/v1/users/badges to get all badges with user stats (progression, achievement...) in a transformed format
GET http://localhost/api/v1/users/{uuid}/badges to get all badges with user stats (progression, achievement...) in a transformed format for the specified user, if his profile is public
Now I have a lot of /users/XYZ endpoints, but my code seems easier to read & maintain, and I don't really need to see the code to guess what data will be returned, the conditions, etc...
I keep wondering how the other APIs are written when you have an admin section, because having /users everywhere isn't really "pretty", and I don't see that anywhere else.
Is there a efficient way of creating an activity log for a user. When the user changes the data log it, when admin changes there data log it and so on. Only way Im thing of doing this is posting at every api request.
One option is to log every single method that you want to be logged.
If you want to save time you can look at Spring AOP which allows you to extract a cross cutting concern, such as logging, into a seperate configuration file and then you can target a whole set of methods based on whatever criteria you choose (pointcut).
https://www.baeldung.com/spring-aop
I've been doing a lot of tutorials for different MVC frameworks, and it seems very typical for Authorization to take place in the Controller. Why?
My thought is the Controller should only be used to orchestrate Model actions, to handle redirection and to handle error events. These are the things that are dependent on the specific request. Putting Authorization in the Controller seems like you're going to have to duplicate the authorization whenever you're using the same Model action in different Controller actions or different Controllers. If Auth is in the Model, you have consistent requirements for carrying out an action or state change on the data.
I've been googling and looking at other questions such as Should authorization be part of the model or controller? but I don't really see why it's the accepted convention.
Is there a specific reason I'm missing for putting Authorization in the controller over the model?
To sum up points in the comments:
Controllers are responsible for altering the state of the model layer and the current view. Nothing else.
Authorization belongs where an action is being carried out, if you're following a strict MVC pattern this would most likely be the model, and a Controller is certainly not responsible for authorizing the use of model actions.
Cookies should be treated like any other datastore: abstracted and used within the models, not directly by controllers.
Authentication and Authorization are separate issues, though they both usually go in the model layer, because they usually involve checks against values in datastores (such as cookies).
Is there a specific reason I'm missing for putting Authorization in the controller over the model?
Well, the most common reason I can imagine is laziness. I don't mean that morally, it's just far easier to flunge some authorization concept on top into a layer that is more close to the concrete request then to have differentiated access on the model layer. To have authorization with the models is a much higher design.
To add some more practical advice to the answer, I think you should analyse for each program where and for what you would want to introduce authorization. The needs for that can be (extremely) different.
Then only in the next step you should think about which design is most beneficial to introduce authorization and authentication to fulfill these needs.
In an MVC approach, you need to put security in a location where:
it cannot be circumvented
it can be configured, managed and updated easily
This applies - as a matter of fact - to any architecture / type of application.
Specifically, in MVC, imagine you put authorization in the view. For instance you decide to control who can approve a transaction by enabling / disabling a button. A user of your view will not be able to approve a transaction if he/she is not allowed. Imagine now that you expose your controller over an API rather than a view. The approve authorization check now needs to be reimplemented in the API layer.
This example shows you are better off moving authorization away from the view / the different end-points and into a common, central point - your controller.
Similarly, if you want to control access to large sets of data (e.g. medical records), you ideally want to put the authorization in the model. This is both for performance reasons and for security reasons: you'd rather have the controller handle less data and you should always strive to protect as close as possible to the source of the sensitive data.
Note that having authorization hooks / checks in the view, controller, and model at the same time may lead to an altogether enhanced experience. See authorization in the view as a "safety / usability" mechanism whereby a user is only presenetd with those relevant menus and widgets on screen based on their permissions. If they were malicious and knew their way around the UI to the controller, authorization there would still kick in.
Finally, generally speaking, you want to decouple non-functional requirements / logic from functional requirements / logic. Much like you do not implement logging in code but use a configurable framework (e.g. Log4J) or you rely on the container for authentication (e.g. HTTP BASIC in Apache Tomcat), you want to use an externalized authorization framework such as Claims-based authorization in the Microsofct MVC4 world, Spring Security in Java, CanCan in Ruby, or XACML, a standard part of the same body as SAML (OASIS) and which will let you apply authorization to any type of application and any layer.
Authorization as an entire process should be involved in both: Controller and Model layers.
But, all the logc (SQL queries, etc) should definitely happen in the model.
Controller is kind of an intermediate layer between the view (representation) and the Model.
But, you simply cannot throw away the Controller from this scheme, because Controller is responsible for handling Sessions and Cookies. Without these two things all your Authentication/Authorization logic is useless, because it is stateless by its nature. Sessions and Cookies bring state to it.
Moreover, as you correctly mentioned, Controller is responsible for redirects.
I'm writing a web application with some ACL requirements: a user can make changes to some items, some items may be editable by several users, administrator can edit anything and a manager can edit everything within her organization etc.
I'm using the Play! framework, and by the looks of the Secure module, it seems that the place to put authorization concerns is in the Controllers. However, it seems to me that the authorization issues are part of the business logic, and therefore should be in the model. Furthermore, I'm starting to see duplicated logic in the controllers that I need to refactor out.
On the other hand, adding authorization to the model means that I'd have to have some way of getting the current user from within the model, which doesn't seem right. Alternatively, I could add a "current_user" parameter to every model method, but that seems even worse.
So what is the common practice? Can/should I put authorization code in the model, or keep it in the controller?
I think this is a grey area. One could argue that the user access is part of the mapping between the HTTP world and the Object-Oriented world. This is what the controller is intended for (hence the heavy use of statics), to transform the incoming request, ready to process the business rules on the domain model.
I would suggest that the controller logic is absolutely the right place for controlling the access to the model, especially as this is managed largely at an annotation level, and the authentication is abstracted off to a Security class.
Authorization should neither be part of controller or domain model.
Instead it should be in the service layer.
Controller should just act as dispatcher and delegate between HTTP and application service.
It's the application service where the orchestration takes place. This is the best place for placing authorization.
Suppose user A is authorized to access data from domain X, but not authorized for even a read access for data from domain Y. If authorization is placed in the controller, then user A gets authorized in the controller X, and via the service calls can access data from domain Y, which is not what we expected.
Since domain models communicate with each other on service layer, hence it best to place the authorization on the same level.
In most cases, the security should be one (or more) layer above the Model. Security is a domain on it's own, restricting access to a lower level layer.
I don't think the security should be done at the controller level.
In my opinion, this should look like that:
View -> Controller -> Security -> Model
The security layer could be a façade or a proxy over the model, protecting access, but be transparent to the controller.
However, if the views are to be modified depending on the access rights of the user, some checks might have to happen at the controller level (like setting the value of a CanEdit boolean property on the ViewModel).
I personally really like the way the Play! Secure module handles this (the tutorial is ever-helpful here). If you don't mind using the #Before annotation, it's pretty painless.
I am at this stage and intending to handle this in the following way:
No form validation by JS, instead via HTTPS ajax
An Ajax php class
Form data sent to a model as its data for concrete validation for
common type such as email and password (likely assoc array validation will be reused by other classes so this is definately a model area).
if no error a lookup in a User table for the credentials email /
password credentials passed to a Controller with the authentication
type such as login / signup / password reset
the controller then produces the required output view or sets user logged in session etc
This is based in Laravel but I have my own library as want it independent of laravel and just loosely based for this vital requirement.
The point being that the Model looks up the required credentials as data, then sends to the Controller as it does not care how it should be processed. I think this is the only way to make this area a definitive responsibility between each of the components.
From my personal experience with MVC frameworks I would say:
Model is an object that is representing database table it should be
pure and should not contain any additional logic.
Controller is the place where are made the decisions and other
custom logic, so the authorization should be in the controller. It
could be designed some hook that can check if the user is authorized
or not in all needed places so you wont have a code repetition DRY.
The best way to give permission to user if you are using a typical
REST architecture is to make a token , save it in the databse and on
client side and verify this token on every request. If you are using
web browser app you can use server-side sessions for authorization (
Its much more easier).
So my propose is to keep the authorization logic in the Controller.
I'll use Rails as an example. The authorization library, pundit, places authorization firmly within the "model" domain - this is enforced through their helper methods.
Suppose you have a ShoppingBag model. You might want to create a ShoppingBag
class ShoppingBagController
def create
authorize ShoppingBag.new, current_user
end
end
It works really well if you have a 1-1 mapping between a model and a controller. But what if you need a second controller on the same model? Now you're stuck!
class DiscountedShoppingBagController
def create
authorize ShoppingBag.new, current_user # does not work for us. we want a slightly different authorization, on the same model.
end
end
It's for that reason I dislike pundit, and CanCanCan. Authorization at the controller level, for me, is ideal. Doing so on the model level limits me too much, without any commensurate gain.
On a website I am building I need to allow users to edit their orders. Easy enough. But how do I ensure that a user cannot edit other users' orders? Do I perform checks in the model or in the controller to verify that the order belongs to the authenticated user?
Put checks in the view (yes, the view) for rapid response to user errors.
Put checks in the controller to ensure data integrity.
For example, in a web based app, you might have browser javascript to check all fields, including username, so the user gets rapid response to fix erroneous transactions. However, back at your server, you can not rely on the browser to really validate the data, since the browser is outside your control -- it might be corrupted, either intentionally or accidentally, and not doing validation as you intend. Thus you need to revalidate everything on your server to ensure integrity.
Well hopefully your site doesn't have any way for a user to even attempt to edit someone else's orders. But if it's still possible to try, you could put that logic in either the model or controller. It's a matter of opinion. Some people will say that the controller should do things like access checks, and the model only knows how to modify itself. Others will say "fat model, skinny controller" and say that the security checks need to be reusable across controllers and so they should go in the model. It's your call.