I'm currently trying to figure out the best way to implement doctrine persisted Role entities as a M2M relationship compatible with FOSUserBundle. Previously I was using just strings with the default implementation and was persisting it with a doctrine array mapping.
Now I need to have roles as seperate entites as we want to build an admin backend where others can grant users roles.
Basically, it's a pain in the ass. The FOS interfaces are built for string representations, not Role entities. Change the implementation, you break a lot of stuff i.e. FOS commands to promote users. And it's hard to figure out exactly which pieces of the interfaces are needed to allow the symfony2 security system to continue working correctly.
I could rewrite the role management code and use Role entities as much as possible, e.g.:
$user->addRole(new Role('ROLE_FOO'));
But that breaks commands and possibly existing code?
Or continue using:
$user->addRole('ROLE_FOO');
And couple role/entity manager code in addRole() (bad design).
I've noticed this is a grey area (Role entities with FOS) and has been mentioned on the symfony2 boards and round here, but no decent solutions.
Anyone had any experience or can think of a decent solution?
I decided to go with a mix of an array/ArrayCollection implementation. I tried to follow the existing interfaces as much as possible so as not to break the security system. I have documented my solution at http://blog.jmoz.co.uk/symfony2-fosuserbundle-role-entities
Related
At the company where I'm working we want to create a complex admin for a new project. We have the following requirements:
Should restrict the list of objects an user has access.
Have a log of changes to the entities.
Permisions based on role of user and group he belongs (think for goup as organization). The user can manage entities that are created by users of the same organization. When a entity is created, a owner is assigned.
RESTfull
We considered SonataAdmin, EasyAdmin or creating an admin with SyliusResourceBundle and SyliusGridBundle.
The questions for SonataAdmin and EesyAdmin are if it is easy to manage permissions based on roles and the organization the user belongs to. Also, we are not sure if it will be complex to made it able to make it RESTfull.
Our questions regarding to SyliusResourceBundle and SyliusGridBundle are if it is too complex to create an admin generator with this two components. On the other hand we think it is more flexible on configuring to use custom managers (to envolve the repositories) in SyliusResourceBundle then SonataAdmin and EasyAdmin. Is that true?
What do you thing of this options? Are there other options?
I can only answer the first of your questions. Will be not easy to implement this future on EasyAdmin and as it's owner say to me:
"If this feature is essential to your backend, I recommend you to use
SonataAdminBundle instead"
This are some post when you can find some clues about how to do it here, here and here. You can see the intention of it's owner to develop this feature in the near future,but not ready yet, so Sonata still remain as the best option. The problem with sonata is that still isn't fully compatible with symfony3 in an stable version, so it's only recommended with symfony 2.7.
Hope this information help you.
In my project I have API Bundle and Dashboard Bundle where I reuse Entities like Client, User, Store etc in both bundles. All entities are in API Bundle at the moment, however I have a feeling that they should be stored in a different Bundle, something like Generic Bundle.
Does anyone has a Best Practice for that?
I read this question about relationships, but it speaks about relationships and not Best Practice.
Thanks.
I don't think there is really one best practice here but the key is re-usability. Let's say down the road for some reason you decide to run the API & Dashboard as 2 separate services. Having a UserBundle with your Client & User Entities means you'll just need to install that on both services along with either the API or Dashboard bundle. You could then also have a service with only your UserBundle that handles the login, ect... Same thing for the Store, I would personally decouple that as much as I could.
But the real question is if it is necessary ? Would you reuse that UserBundle in another project ? Do you plan on splitting the project as services down the road ?
Ultimately the specifics are really up to you, a GenericBundle could be all you need or you might have enough to separate into UserBundle & StoreBundle for example.
Which are the best user manager bundles for Symfony 2 and why?
I only know FOSUserBundle.
Are there other good bundles for managing users?
(like it was sfDoctrineGuardPlugin for Symfony 1)
I need not a final, closed solution, but the pros and contras for someone to be able to choose the best bundle depending on his needs.
Firstly, i wrote an UserBundle implementation for my requirements, after i discovered FOSUserBundle and i learned best practices from it.
I think FosUserBundle is a good choice for user manager in Symfony 2. Because
Actively maintained and supported
Provides command line commands for creating new user, activating, promoting etc.
Built-in forms, controllers and views for user related actions.
Supports Doctrine, Propel, CouchDB and Mongo for persistance.
Localization, translations
Optional features like email activation
Supported by other bundles like Sonata bundles
I never worked with other UserBundle, but i highly recommend to use FOSUserBundle.
I'm developing a SaaS where tenants are both real ones and admins (us). So "fornt-end" and "back-end" are the same. Anyway, according to many other questions bundles are a way to structure your project in reusable way.
I really don't think that our bundles are going to be reused, but i still need a way to split the project into bundles to quickly find files we want to work on. Application should:
CRUD for customers - tenants should be able to manage their
customers/partnerships
CRUD for customers tags and keywords (a way to categorize their customers)
CRUD for broadcast notifications sent by us (a messaging system)
CRUD for tenants - we should be able to manage our tenants
So, how can organize my bundles? Could be:
CoreBundle: only Doctrine2 models
ResourcesBundle: templates, js, css, images
SystemUserBundle: manage tenants and customers CRUD
MessagingBundle: message system
How this design can be improved?
According to the Symfony2 documentation:
In Symfony2, a bundle is like a plugin, except that all of the code in
your application will live inside a bundle. A bundle is nothing more
than a directory that houses everything related to a specific feature,
including PHP classes, configuration, and even stylesheets and
Javascript files (see The Bundle System).
Personally, following this description, I would set up the SystemUserBundle to contain the Doctrine2 model and templates/js/css/images that specifically relate to managing customers, rather than splitting them out into CoreBundle and ResourceBundle. However, splitting your app into SystemUserBundle and MessagingBundle sounds like a reasonable approach.
I like to think of it this way - does the bundle encapsulate some behaviour that I might need or want to plugin to a future Symfony project(s) I am involved in. Customer Management, for example, is something that might apply to any app and be re-used across projects (indeed, this is why the extensible FOSUserBundle exists).
I don't think the Symfony2 docs go into sufficient detail on bundles (yet!) but in case you haven't found all the relevant sections these are the ones I'm aware of:
Symfony 2 Page creation
Symfony 2 The Bundle System
Symfony 2 Bundles best practices
I'm new to EF4 and haven't had any experience with it before. So, bear with me if this is very simple question.
I have my POCO entities (.tt file) in BOL, the .edmx file (EDM) in DAL and my webapp in Presentation layer. All the business logic goes to BLL layer.
Here are the references:
UI->BLL-DAL-BOL
BLL->DAL-BOL
DAL->BOL
BOL->None of my project.
1- Is my understanding of layers distinction correct? Am I in the right direction?
2- How can I use ASP.NET Membership provider with entities. Should I implement membership, persistence ignorant too and map all user tables in sql server to entities?
2- How can I add custom validation? I don't mean maxlength or valid email..., I mean something like access levels. For example I want certain users be able to modify a field (say productprice) in my website. Where should I use the User.IsInRole method? the BLL doesn't have any reference to user info. should I pass some parameters to BLL (like "bool CanChangePrice") to clarify access levels?
Wow Kamyar, just a few questions wrapped up in this one;-) I'm not sure if I'll cover all the possible ground, but here goes.
ProjectStructure
- generally your structure of projects is correct, and the references you have are correct. Some may argue that you want to separate your concerns a bit and break some of the references, but personally I find your structure workable.
As a practical matter I tend to keep my EDXM and POCOs in the same project. I just have an Entities folder that contains the EDXM and Model.Context.tt, a POCO folder for Model.tt and my Virtual POCO's (below), and a Repository folder for my repository & unit of work.
I also create a file called VirtualPOCOs which is a partial class bound to the POCOs generated by your T4's. My designs tend to be pretty tightly bound to database structure. The VirtualPOCO's give me a little flexibility to deviate from DB design in those one-off situations. Not to much goes in here, just those few very specific needs every project seems to have.
You may also want to consider a repository, table data gateway, or active record setup. All of these patterns will likely be combined with Unit of Work. There are tons of design patterns and your needs or preferences may push you to one or the other. The point here is to shield the upper layers from accessing the EF4 context directly. This way you can centralize connection & transaction management and ensure upper layers are only using POCOs and not accidentally holding on to linq-to-sql objects.
Membership Provider
There is a definitely a schism between the MembershipProvider and EF. You can, however, download the source code for the SQLMembershipProvider and convert it over to use EF. I actually did this conversion. The file is about 1500 lines long, but doesn't have a huge amount of ADO code.
What you didn't ask, but I think I should address, is whether you want to use Membership provider at all. If you're doing basic membership management and roles then the Membership, Roles, and Profile provider can save you a lot of time. For an in depth tour of the capabilities check out the series over at 4GuysFromRolla (https://web.archive.org/web/20211020202857/http://www.4guysfromrolla.com/articles/120705-1.aspx).
If your needs are more complex then, IMHO, the membership provider breaks down pretty quickly. For example, when a user registers for your site you immediately have to create rows in a handful of different tables. Well, the membership provider is registered through webconfig and uses the membership provider interface. It only accepts certain fields in the create function. So what's a boy to do? Well, you can open a larger scale transaction up in your controller, run the membership providers add user function, run your own MyCustomUserStuff(), then commit the transaction. Two reasons I find this unappealing are that I've now got transactional code seeping way up my call stack and if all I need to do is add a few extra fields I've now doubled my database calls needlessly.
I guess I just found the membership provider pretty restricting, and once got in there and made my own custom membership provider the benefits of using MS's model quickly fell away.
Validation
I think the answer here is a resounding --it depends. Are your permissions pretty static? i.e. those in the "SiteManagers" group can edit all over the site? Or are your permissions much more fine grained? Meaning SiteManagers have access to these 75 fields spread across these 22 tables, or is it more table based? Additionally, how mutable are the permissions ? Does your site admin need to be able to frequently turn access on/off or off to various fields in different tables?
I think I need to hear more on your requirements for a specific answer. Keep in mind that the more fine grained you make your permissions the more of a configuration headache the client will have understanding & managing all the permissions.
Also, what back-end are you using? Many DBA's face these decisions. One often used strategy in that world is to create a series of views where each view exposes the columns users have. For example, the EmployeesHR view would expose just those columns that HR people have access to, and the EmployeeDirectory would expose just those fields that the directory has access to.Then HR users are given permission to the HR view, but not the underlying table. Just a thought.
Anyway, hope this helps.
1- Your distinction of the layers seem correct to me.
I wouldn't reference the DAL in the UI, as in my projects, I prefer that only the middle layer access the DAL. But it's not wrong.
So you seem in the right direction.
2- To my knowledge there is no MembershipProvider that works with EF.
So in projects where we used Membership, here is what we did :
created the tables with the aspnet_regsql.exe
configure the Web.Config to use the SqlMembershiptProvider
added in the web.config ANOTHER connection string (one for Membership and one for EF)
Built the EDMX file with all tables, including the Membership ones.
In the code, a UserManager / RoleManager (BLL or DAL it depends on your architecture) get the informations using standard Membership methods. And always use the Membership objects, not EF ones. So in fact the user / roles management part is separated from the EF.
We only use the aspnet_* EF entities when there is a link between your custom tables and a Membership table (for instance, when you want to link one of your table with the aspnet_Users table to keep a reference of the user that inserted a data).
3- For the right management, I would use a BLL RightManager that would allow the UI to know if the user can change the field (so you can disable it, or prevent input), and to use this information in your validation method.
In my project I use a Right table and I associate a Right with a Role. In the RightManager provide a RequestRight(Right) method.
If your Right management is too simple to create tables, just use User.IsInRole() in your RightManager (so I would use it in BLL).
I would place the validation method in the UI if it is "basic" and in the BLL if it contains more complex rules (involving DAL access for instance).
about EF & Membership
as i know, you dont need to use any db provider instead of membership provider
but if you want, you can map membership tables in EF and create additional method to
common provider