In my Laravel application, I have a Model called Project which has, among others, a property called approved_at. There is also a ProjectController, which contains the usual methods *(index, show, create, update, edit...)
Now, the user that created the Project can edit it (modifying its other attributes), but only some "staff" members have the right to approve one.
From what I understand, there can be two ways to handle the approval operation:
Both users, from their respective views (let's call them edit and approve) fire the ProjectController#update method, which will internally distinguish who-can-do-what by means of authorization or policies;
I create a new ProjectApprovalController, with its own update method, and check the authorization at the endpoint (eg, /projects/{id}/approve).
What is the best approach to tackle this behaviour?
It depends on what do you want to do with this in the future. If there would be some kind of extra steps to do behind the approve method for example: connection to external micro service to check if project exists in external database with subsidies then you should definitely split it.
If you don’t mind I would suggest you to not focus so much on the implementation. Your application should be removable as fast as you build it. There is a great presentation about this from Greg Young called ‘The Art of
Destroying Software’. Be more focus to build your solution with SOLID principles and test the behaviour of this method to make it easier to replace in the future.
to answer your question, second option is more restful approach, but I don’t know if that is not shooting to fly with a cannon
Related
I'm starting with Symfony 3, and I need some guidance about how to proceed with the process of implementing dynamic authorization and authentication.
First of all, the authentication bit is mostly done, I've done it according to this link from symfony docs: http://symfony.com/doc/current/security/entity_provider.html. What I'm yet to understand is how to implement the interface function getRoles() in order to return a value from the database (I have a table Role related to the User table).
Secondly, the authorization part. My application will require the end user to create his own access mechanism, in other words, I have an interface where the user creates a Role, then defines what pages that Role will be able to access and what privileges it'll have (create, read, update, delete, and so on). Afterwards the roles are attributed to the application users.
All in all it is pretty standard stuff so Symfony must have a clean way to do it. What I figured out so far is that I'll have to use ACLs, so I did as in the docs: http://symfony.com/doc/current/security/acl.html
My honest question here is: What now? What steps do I take to fully implement the authentication mechanism? What should I do now in order to persist and retrieve the access rules? How do I relate them with the user Roles?
P.S.: This question might be sort of a duplicate of some other questions here, but truth being told, those questions did not help me either, nor my scavenging in the docs did.
So, your question is very broad. Anyway it is a good question, so I'm going to try to reply.
THE AUTHENTICATION
Nothing to say here, I simply hope you used FOSUserBundle as suggested by the article itself: is the best way to implement a registration/login system in Symfony and it will give you an idea of how the entire process works. Starting from scratch if you are not a Symfony experienced developer seems to not be the best idea.
Give FOSUserBundle a try!
THE AUTHORIZATION PROCESS
About authorization you have basically two options: the use of Voters and the use of ACL.
In my experience the best option is ever the use of Voters.
In most cases, in fact, you will have a bidirectional reference (see Doctrine's documentation about this) in your entities between the User and the object on which (s)he have rights. In this case the ACL is not required and even discouraged.
In fact, the ACL does nothing more than creating a relationship between two objects (the User and the Article in your use case). To manage this relationship it uses a table in the database and so it has to query it to get the relationship and check for the authorization rights.
But if you already have a bidirectional reference between the User and the Article/Group directly in your entities, then you already have this relationship in place and so you can use Voters and the use of the ACL is superfluous and even, as said, discouraged as it is a useless duplication.
If you don't have this bidirectional relationship in your entities, then create it: it will be certainly useful in the future for other things and, anyway, you will have ever the ability to access your linked entities directly from your entities tree!
More, in your scenario, you cannot use ACL as you will have custom rights/privileges on your objects: the voters, again, are the best option to build this kind of things.
Don't use ACL, but Voters instead
HOW TO PROCEED
The first thing I would do, is to list in an interface all the available privileges: after all, they are strictly related to your application business logic, as it is not possible for a user to make someone able to do something that your app cannot do: if your application doesn't implement an editing flow, then it is not possible for a user to give someone the ability to edit an article. It's obvious.
So, something like this may be good:
interface PrivilegesEnum
{
const CREATE = 1;
const EDIT = 2;
const DELETE = 4;
const READ = 8;
const OTHER = 16;
// ... Other privileges
}
As you can see, I've given a numeric value to each privilege: this will give you the ability to use bitmasks that is a really powerful mechanism to manage this kind of things: it allows you to use only one field in the database to list all the privileges.
You can read more about bitmasks here:
https://www.google.it/search?q=bitmask+php+example
How to implement a bitmask in php?
Why should I use bitwise/bitmask in PHP?
http://alanhollis.com/a-quick-guide-to-using-bitmasks-for-permissions-in-php/
https://codereview.stackexchange.com/questions/1509/php-bitmask-class
https://www.google.it/search?q=php+bitmask+theory
How to implement a bitmask in php?
http://php.net/manual/en/language.operators.bitwise.php
http://php.net/manual/it/language.operators.bitwise.php
https://code.tutsplus.com/articles/understanding-bitwise-operators--active-11301
https://code.tutsplus.com/articles/number-systems-an-introduction-to-binary-hexadecimal-and-more--active-10848
I used this system in the past and those are some useful links I collected. They might help you!
BUILD A FORM TO LIST PRIVILEGES
Another thing you may find useful is a FormType to list your available privileges: you can do this writing a simple custom FormType.
HOW TO MANAGE ROLES
To manage roles read how Roles are managed by the Security Component and in FOSUserBundle (on Stackoverflow)
THE RELATIONSHIP BETWEEN USERS AND GROUPS AND ARTICLES
Once you reached this point you should have some more entities, read more about Doctrine relationship mechanisms knowing it better and you should be able to relate your users with their role, their group and the articles.
Anyway you will have all the required conceptual and practical tools needed to think better at your concrete implementation.
FINAL NOTE
As you can see, implement such type how authorization process isn't so simple.
I suggest you to think very carefully if it is really required in this stage of the development of your app, because if you can defer it in the future, then I suggest you to do it.
If you want to go online as fast as possible, implementing this system will require a lot of time to learn, implement, debug and refact the code (I'm speaking of weeks, not days!).
So, if you have all this time, then, go to implement this system. But if you feel you haven't all this time, then go with a more "static" system, go online, and then make it more "dynamic".
After all, this is the Lean Startup era!
Good luck!
How do you handle situation with blameable in the DDD way?
Ofcourse we can ignore some things, but i think that when entity need some tracking (creator, updater, time updated / created) it should be in the class that actually performs some actions on entity.
For example we have post and user, what whould be the correct way?
$post = new Post();
$post->create(); // here we can set some created_id and
other attributes by using mixins or traits like some fw do
Or it is better like this:
$user->createPost($post);
$user->update($post);
As for me second is better, even when we need to track changes that does not apply to post directly, for example:
$post->doSomethingWithPost();
$user->updatePost($post);
Seems like blameable just throws out one important entity - user who manages some things on entities.
Ofcourse we should not overcomplicate things, but usually when blameable is implemented, entity from which you will get id is a logged in user, that is incorrect to the bounded context.
Here it is some Blogging Context, where user of this context updates post and not some authenticated user.
Whats your thoughts on this one? Is there some similar questions that i maybe missed?
All your examples seem like they are not designed with the DDD principles in mind. The first indicator to me is the usage of a $user variable. In 99% of the cases this is too generic to really capture the intent of a given Model. I think there are hidden concepts that would first have to be made explicit. I think along the lines of RegisteredAuthor and Administrator. At least that's what I understand from:
Here it is some Blogging Context, where user of this context updates post and not some authenticated user.
Another question is how can a "user of this context" not be authenticated? How do you know who he is?
In general in an application that explicitly requires User management we normally have something like an IdentityContext as a supporting Sub Domain. In the different contexts we then have other Models like Author or BlogAdministrator holding a reference to the User's identity (UserId) from the IdentityContext. The Red Book has some nice examples on how to implement this.
To answer the question on how to track who changed something and when:
This concept is also referred to as Auditability, which in most revenue relevant parts of system is actually a must once your organization is reaching a certain size. In this scenario I actually always recommend an Event Sourcing approach since it comes with auditability batteries included.
In your case it would actually be enough to either capture the executing UserId as Metadata to the commands like WritePostCommand or ChangePostContentsCommand or use the UserId in a RequestContext object that knows about the execution context (who was sending this command, when was it sent, is this user allowed to execute this use case).
You can then, as Alexander Langer pointed out in the comments, just use this metadata inside your Repositories or Handlers to pass the information to the Aggregates that need it, or could even just send them to an audit log to not pollute your Domain Model with this responsibilities.
NOTE: Generally I would not use the DoctrineExtensions like Blameable in your Domain Model. They depend heavily on Doctrine's Event system, and you do not want to tie your Model into an Infrastructure concern.
Kind regards
I'd like to ask other opinions about code structuring of business logic on Laravel applications, mainly regarding permissions at the row level.
For those that don't know it, Laravel is a MVC framework for PHP, much like Rails.
For the sake of understanding, let's suppose a multi-tenant application where each user has his own albums and pictures, so far so good.
Now, each user can invite others to collaborate (by uploading photos) into his album.
Both, the album's owner and collaborator that uploaded the picture may be able to delete or update information about that picture.
Only the owner may edit the album and invite new collaborators.
Collaborators can remove themselves of the album if they want so.
Pinterest should be a nice example of something similar, but our application is probably 3 or 4 times more complex.
The question is: where should I handle that kind of logic?
Laravel proposes the approach of having repositories, entities and services, which I don't fully understand, probably because of the lack of good examples. So the obvious first choice to meet those deadlines was to put it all on controllers (ew!). Now, digging into refactoring, there are many possible ways to un'spaghettize our code:
I've seen people implement ACL at row level (looks kinda dumb and overkill)
It would be possible to turn models into behavior aware objects and not only data containers, something like $album->add_photo($photo) and check permissions at that function
It would also be possible to override model's save method and do there those checks
Or, follow the Laravel proposed road of having separate layers of concern
I suppose that having methods like $album->can_be_edited_by($user) may simplify the displaying of 404 erros on routes not allowed, hiding view's links as well as validating before saving the models
Which would you recommend, and does anyone know any simple, but understandable, example of repositories, entities and services not using .NET?
Thanks!
Edit: I guess that a full ACL system would cause excessive overhead, since there may be thousands of resources associated with each user, but only one role per kind of association. For instance, pictures will have an uploader_id and albums will have an owner_id.
I could be wrong but I think ACLs are OBJECT based permissions (i.e., a user can or can't delete photos in GENERAL). What you want is more custom MODEL based permissions (row level like you said), i.e., a user can delete photos that they themselves created (SPECIFIC ones).
Most Laravel packages are designed for object based permissions I think, but not https://github.com/deefour/authorizer - this one is a great hidden gem. We don't use it in our project but I found that it really covers all the bases we'd need.
We have really advanced model permissions on our app, I have them scattered throughout my models, but I take a very model centric approach, which isn't necessarily very "laravel-esque". In your example with delete, I would override the delete method in your model or listen for the eloquent event and prevent it there. If you have to prevent read/write on certain attributes you could even do that by extending your validator or using custom mutators/getters, serializers or listening on events. More on where to add business logic in my question/answer here: https://stackoverflow.com/a/27804817/796437
I'm still trying to find the best approach, if I do I'll update this - but thought I'd post.
In Laravel you can use Policies or use solutions, like Symfony Voters.
For Laravel exists same package - Laravel Simple Voters.
Using this, you can check access to custom objects, looks like this:
Access::isGranted('edit', $post) // current user can edit this post?
You can put this logic, to example, into middleware, if you wish check requests to controllers.
My problem is in somewhere between model and controller.Everything works perfect for me when I use MVC just for crud (create, read, update, delete).I have separate models for each database table .I access these models from controller , to crud them . For example , in contacts application,I have actions (create, read, update, delete) in controller(contact) to use model's (contact) methods (create, read, update, delete).
The problem starts when I try to do something more complicated. There are some complex processes which I do not know where should I put them.
For example , in registering user process. I can not just finish this process in user model because , I have to use other models too (sending mails , creating other records for user via other models) and do lots of complex validations via other models.
For example , in some complex searching processes , I have to access lots of models (articles, videos, images etc.)
Or, sometimes , I have to use apis to decide what I will do next or which database model I will use to record data
So where is the place to do this complicated processes. I do not want to do them in controllers , Because sometimes I should use these processes in other controllers too. And I do not want to put these process in models because , I use models as database access layers .May be I am wrong,I want to know . Thank you for your answer .
Just a short comment (no solution) AFAIK that is an eternal question - MVC is just a pattern, and as such, is in theory implementable cleanly. In practise, due to limitations set by available tools (such as programming language library contents and UI component interface design..) you have to make local decisions. The important thing is that you aim to separate these...and not have everything in one mess. I take my comment off the air and am left to see if someone has a "final solution".
For simple tasks I would write action helpers (e.g. sendNewsletter).
For sophistocated tasks I woud create services (eg. email, auth etc.).
In MVC, you should place those things in the model (for reuse reasons for one).
However, in HVMC, you could place them wherever (such as in a controller) and call the controllers from within your application.
I would make your controllers simple.
In many ways the model allows you to offload a lot of the complexity that would otherwise occlude your controller code. Its this division of complexity which will make your code more easily understood, and easier to maintain.
personally I try to keep my models resembling real world objects, not databases tables or rows. It makes it much easier if you have made things speak in more readable terms. A single real world object might involve 5 or 6 database tables... And it would be a rather large hassle to speak with 5 or 6 models, when all you want to do is turn on a switch, or pick a flower, or paint an icon, or send a message.
What's wrong with a controller using multiple models? Isn't the point of MVC to make the model reusable? In your first scenario, it's perfectly fine to send emails and manipulate other model objects from wherever the "register user" controller code is.
In regard to your second scenario, why can't SearchController use ArticleModel, ImageModel and VideoModel? It's fine to have a controller without a model. SearchController doesn't need a SearchModel class, it just uses the other model classes.
I'm trying not to get into a rant about MVC in web apps, but basically, IMHO the controller is just a high-level list of steps to complete an operation. As a rough example, the "register user" controller code should do each of the following steps in roughly one or two lines of code:
Validate the input
If not valid, redisplay the form with an error
Create the new UserModel object from the form input
Insert the new UserModel object into the database
Create/edit whatever other model objects are necessary
Send off an email to the new user
Display a "registration successful" page
How those steps are coded largely depends on whatever framework/architecture you're using.
Keep your controllers clean. For backend processing use Manager classes like MailManager etc..
1) Where does the homepage of your website fit into "controllers"? I've seen some people use a "page" controller to handle static pages like, about, home, contact, etc., but to me this doesn't seem like a good idea. Would creating a distinct controller just for your homepage be a better option? After all, it may need to access multiple models and doesn't really flow well with the whole, one controller per model theory that some people use.
2) If you need a dashboard for multiple types of users, would that be one dashboard controller that would have toggle code dependent upon which user, or would you have say a dashboard action within each controller per user? For example, admin/dashboard, account/dashboard, etc.
3) It seems to me that using the whole simple CRUD example works like a charm when trying to explain controllers, but that once you get past those simple functions, it breaks down and can cause your controllers to get unwieldy. Why do some people choose to create a login controller, when others make a login function in a user controller? One reason I think is that a lot of us come from a page approach background and it's hard to think of controllers as "objects" or "nouns" because pages don't always work that way. Case in point why on earth would you want to create a "pages" controller that would handle pages that really have nothing to do with each other just to have a "container" to fit actions into. Just doesn't seem right to me.
4) Should controllers have more to do with a use case than an "object" that actions can be performed on? For all intensive purposes, you could create a user controller that does every action in your whole app. Or you could create a controller per "area of concern" as some like to say. Or you could create one controller per view if you wanted. There is so much leeway that it makes it tough to figure out a consistent method to use.
Controllers shouldn't be this confusing probably, but for some reason they baffle the hell out of me. Any helpful comments would be greatly appreciated.
1) I use a simple homebrew set of classes for some of my MVC stuff, and it relates controller names to action and view names (it's a Front Controller style, similar to Zend). For a generic web site, let's assume it has a home page, privacy policy, contact page and an about page. I don't really want to make separate controllers for all these things, so I'll stick them inside my IndexController, with function names like actionIndex(), actionPrivacy(), actionContact(), and actionAbout().
To go along with that, inside my Views directory I have a directory of templates associated with each action. By default, any action automatically looks for an associated template, although you can specify one if you wish. So actionPrivacy() would look for a template file at index/privacy.php, actionContact() would look for index/contact.php, etc.
Of course, this relates to the URLs as well. So a url hit to http://www.example.com/index/about would run actionAbout(), which would load the About page template. Since the about page is completely static content, my actionAbout() does absolutely nothing, other than provide a public action for the Front Controller to see and run.
So to answer the core of your question, I do put multiple "pages" into a single controller, and it works fine for my purposes. One model per controller is a theory I don't think I'd try to follow when working with Web MVC, as it seems to fit an application with state much better.
2) For this, I would have multiple controllers. Following the same methods I use above, I would have /admin/dashboard and /account/dashboard as you suggest, although there's no reason they couldn't use the same (or portions of the same) templates.
I suppose if I had a gazillion different kinds of users, I'd make things more generic and only use one controller, and have a mod_rewrite rule to handle the loading. It would probably depend on how functionally complex the dashboard is, and what the account set up is like.
3) I find CRUD functionality difficult to implement directly into any layer of MVC and still have it be clean, flexible and efficient. I like to abstract CRUD functionality out into a service layer that any object may call upon, and have a base object class from which I can extend any objects needing CRUD.
I would suggest utilizing some of the PHP ORM frameworks out there for CRUD. They can do away with a lot of the hassle of getting a nice implementation.
In terms of login controller versus user controller, I suppose it depends on your application domain. With my style of programming, I would tend to think of "logging in" as a simple operation within the domain of a User model, and thusly have a single operation for it inside a user controller. To be more precise, I would have the UserController instantiate a user model and call a login routine on the model. I can't tell you that this is the proper way, because I couldn't say for sure what the proper way is supposed to be. It's a matter of context.
4) You're right about the leeway. You could easily create a controller that handled everything your app/site wanted to do. However, I think you'd agree that this would become a maintenance nightmare. I still get the jibbly-jibblies thinking about my last job at a market research company, where the internal PHP app was done by an overseas team with what I can only assume was little-to-no training. We're talking 10,000 line scripts that handled the whole site. It was impossible to maintain.
So, I'd suggest you break your app/site down into business domain areas, and create controllers based on that. Figure out the core concepts of your app and go from there.
Example
Let's say I had a web site about manatees, because obviously manatees rock. I'd want some normal site pages (about, contact, etc.), user account management, a forum, a picture gallery, and maybe a research document material area (with the latest science about manatees). Pretty simple, and a lot of it would be static, but you can start to see the breakdown.
IndexController - handles about page, privacy policy, generic static content.
UserController - handles account creation, logging in/out, preferences
PictureController - display pictures, handle uploads
ForumController - probably not much, I'd try to integrate an external forum, which would mean I wouldn't need much functionality here.
LibraryController - show lists of recent news and research
HugAManateeController - virtual manatee hugging in real-time over HTTP
That probably gives you at least a basic separation. If you find a controller becoming extremely large, it's probably time to break down the business domain into separate controllers.
It will be different for every project, so a little planning goes a long way towards what kind of architectural structure you'll have.
Web MVC can get very subjective, as it is quite different from a MVC model where your application has state. I try to keep major functionality out of Controllers when dealing with web apps. I like them to instantiate a few objects or models, run a couple of methods based on the action being taken, and collect some View data to pass off to the View once it's done. The simpler the better, and I put the core business logic into the models, which are supposed to be representative of the state of the application.
Hope that helps.