Hello I have a technical question on how to implement multiple user types (not using FOS). I'll explain what I'm willing to do, I'd like some feedback on what can be done better or a suggestion on how to do it.
I'll have 4 entities
user
amateur
profesional
organisation
The default one that is implemented right now is user. To get things out of the way I'll user a second user provider for organisation as it will not be related to the previous ones.
I'm wondering how to do the User, Amateur, Profesional accounts.
They share most of the basic fields just have additional information to them. Most of them have the same permissions. Whats the best way to do It?
1) Adding a one to one extra entity to the User Class
I'll add a one to one AmateurInformation and ProInformation to the main User class. And determine the account type by a single accountType field.
2) Extending the Class with a child class?
I don't even know that something like this is possible. Also I'd like to make requests to the Repo that will return all User types.
Again I'm looking for suggestions on what to look into and how I can do this. I want to improve my knowledge while I'm at it :)
In my view two suggested solutions are viable (introducing a type field or using inheritance), really depends on your situation.
I would avoid using multiple independent classes, it will just complicate it.
If the relation to other database entries does not justify, it is not required to create separate classes, you can use the type field and maybe introduce specific roles (see getRoles() in UserInterface) for your different users.
If your user classes will have access to different things (relations to other entities), I would consider using a Single Table Inheritance with doctrine. With this solution you still can use one UserProvider and in code you can check the user object, and also, you can use custom roles to give permissions:
if ($user instanceOf Amateur)
Related
My friends, i've come trhough a situation i haven't come before. I have one entity (aka Person ;) that i need to save. But the thing is that i have groups of information of a person that i wish to ask for the user to input in more than one controller, this way the user won't have to fill a extense form. He'll go in steps filling the forms for Personal Info, Academic Info, Job History Info, etc. I'm using MVC 4. Do I have to create one controller to each form/view? Because my entity has all atributes i need to persist at once (by the way i plan to use an ORM, haven't decides if it will be NHibernate or Entity Framework yet). Thx.
You do not need to create a new controller for each view. That's actually not what you want to do. Sounds like you may be coming from WebForms, which would require a different page for each form.
MVC doesn't work like this. Just simply create a new action and view for each page.
As far as persisting data, there are numerous ways to do this. You can use session data, or more preferably, a database(model) to store the data. You can use something like ADO.NET/Entity Framework to help with this so you don't have to mess with the dirty database details.
You may find it useful to instanciate this person entity and preserve the partially filled data in the ViewBag or any other (global variable) that you prefer to use.
this way, what ever design you follow, either single controller, if possible, or multiple. you would just need to get the data from viewbag and persist it into DB.
It will also allow you to navigate in forms easily and data could be populated by using the viewbag.
http://www.silverstripe.org/archive/show/1638
The above post seems like it's what I should do but I just need some help sorting this out in my head.
Firstly, I need to create a relationship between a page (Owner, for example) and a dataobject (Car). An owner can create many cars which are linked to that one owner. However, I have another page (Garage) which can create cars that are linked to every owner. If an owner does not want one of these cars they reject it. I was thinking the manymanydataobjectmanager would be good for that bit.
Each owner should only be able to see the cars that relate directly to them within the CMS, not other peoples cars, so I was using dataobjectmanager and assigning permissions to the page using groups.
The thing that is really making this awkward is that when it's all set up I need to output JSON which will consist of the cars the owners created and the cars they accepted from the garage, not the ones they rejected. I'm thinking I need another table like the linked table but with a status column perhaps?
To clarify, my question is how do I create this mess in a constructive SilverStripe way? Is the approach I was taking correct or is there a better way?
Many thanks in advance and please tell me if I've been unclear.
are you using silverstripe 3?
could you clarify what of the actions happen in the backend and what actions are possible for the user in the frontend?
maybe for your relations it could be better to use ModelAdmin:
http://doc.silverstripe.org/framework/en/reference/modeladmin
It gives you the opportunity to manage relations without the Sitetree/Pages Overhead. For example creating a Sitetree Element just to have an Owner is not the best way - except if you really need an Owner represented as a real Page. Owner could be also just a Dataobject instead.
Especially if you want to output just JSON in the end you are maybe completely independent of Sitetree/Pages... then you could write a custom controller with a routing rule and which gives you back just the data that you need:
http://doc.silverstripe.org/framework/en/topics/controller
regards,
Florian
I am currently developing an web site using asp and have a few questions regarding Membership Provider.
I am currently inheriting from Membership Provider class and have just got over the issue of only certain parameters being able to be passed to the CreateUser method.
I have been able to overcome this issue by creating a class that inherits from MembershipUser adding custom properties and then passing that the the UpdateUser method. However to me this seems quite messy and not very efficient as I am making two calls to the database when I could do it in one if I dont use the CreateUserWizard.
So my question is, is using the Provided Login components worthwhile if you are overriding the methods and require more parameters ect in order to keep the use of the properties you can define for this class in the web.config file or is it easier in the long run to just start from scratch. Basically what I want to know is how people have found using Membership by overriding and inheritance over starting from scratch, and how these compare.
Any webpages that talk about this would be good and apologies if the question doesn't make sense or I have missed anything out.
Thanks,
Ric
If I am understanding your question correctly, then yes the membership provider is a great api to build off of so you don't have to reinvent the wheel for the basics of authentication/authorization.
You are using Membership wrong. You should only create your own custom provider when you need to map onto an existing database. IF you are making your own database, then you should just use the default implementation.
Even if you create a custom implementation, you should not do anything that the current membership doesn't already provide. Just map those functions on to your database.
To add additional information, you create a secondary table called UserData or something. This table will be keyed by the MembershipUser.ProviderUserKey, so you lookup any data you need from the other table using the userid from the membership class.
You're really fighting upstream trying to change membership to give you custom things. You can do it, but why cause yourself trouble?
I'm looking at writing a custom RoleProvider to talk to an external third-party system. However, the "roles" I need aren't explicitly defined in the system but are instead based on conditions within the system. For example, a role might be defined as someone who is assigned to a particular committee or someone who is at a particular level of membership. This means that the system has no concept of the roles I want to use and no mechanism for defining them. Clearly the role maintenance methods are meaningless here and would remain unimplemented, but the role query methods have to have the roles defined somewhere.
How can I define and use a roles in a situation like this? Maintaining a separate database for this information would be a nightmare. In addition, this framework would be used in multiple deployments where the roles would be completely different. I keep thinking that I need to code some sort of system with role objects that contain the logic required to determine if a user is in that particular role, but I can't figure out how to make it work with the Role Provider model.
Am I missing something blatantly obvious? Am I going about this completely wrong?
Well, you could do a few things; you could create a role provider to take their position within your system (committee member, etc.) and translate that into a role string. Obviously, you'd want to do this once and cache them, but that is a possibility.
The other option is to skip the roles feature that's in built, and within your pages just check their status and validate them based upon that; for instance, do they have access to view this committee, check if they are a member, and allow them; otherwise, deny them. That sort of thing.
HTH.
I have created my own Role Provider because I found the one that ASP.Net provides to be way too bulky in terms of tables in the database. I found implementing a custom RoleProvider to be quite easy.
My only problem is that right now I cannot have multiple roles for a page. I saw somewhere that at the top of your class you need to "anotate it" with some security code. This is what I have
[PrincipalPermission(SecurityAction.Demand, Role="Admin")]
If I try to include multiple roles by using a comma separated list I get errors. If i try to specify multiple role keys then I also get errors. Do i Need to specify multiple PrinicipalPermissions by any chance?
I have very little experience with ASP.Net's role management. Can someone point me in the right direction or at some good literature.
you can add the PrinicpalPermission attribute multiple times.
[PrincipalPermission(SecurityAction.Demand, Role="Admin")]
[PrincipalPermission(SecurityAction.Demand, Role="AnotherRole")]
[PrincipalPermission(SecurityAction.Demand, Role="Admin,Another RoleName")]