I am creating a web application using MVC3. I have one database which contains all of the tables I use in the application (including a Users and Roles table, which are the focus of this question).
I have already set it up (very quickly) to Authenticate the user using SetAuthCookie. However as my application has different roles, I also need to be able to find out if the user is in a specific role before they can access specific controllers.
I have spent the last few days trying and failing to implement various solutions from here and general online searches. Topics of discussion have been FormsAuthentication, IIdentity, IPrincipal, MembershipProvider, RoleProvider. And after several failed attempts I am completely confused by everything.
In the past I have used the default accounts stuff using the ASPNET Membership DB, and since I didn't have to touch it at all, had no problems. But I would prefer all of my tables were in the same DB this time around. I would also prefer that I can decorate the controllers with [Authorize], [Role="Sysadmin"] etc.
I am aware that this and similar questions are asked a lot and that there are several resources available which cover the topics described above, but the problem is that the solutions are conflicting, or assume knowledge of other related fields, or the presence of non-standard classes, and even in some cases provide a flawed solution "for simplicity's sake".
So to recap:
I have a blank MVC3 project.
I have a Database with my Users Table and Roles Table (each user can have one role).
I want to decorate the controllers with [Authorize], [Role="Sysadmin"]
I do not care how complex the solution is. I am willing to spend as much time as necessary to get the most secure and efficient solution.
Thanks in advance
You can write custom membership providers, here is a link that explains more:
MVC 3 Customer Membership providers
Related
I'm currently learning myself the Codeigniter framework. I want to create a project that will have a front-end (which will be used by users) and a back-end (which would be used by administrators).
I have looked through different articles, all of them suggest using HMVC to separate the public and admin controllers/views. I have also considered to create two separate projects, one for the public and one for the admin, both using the same database.
I have tried to do research on which one of the methods mentioned above would be the best solution for a potentially large project, but could not come up with any sustainable answer.
Is it possible that two separate CodeIgniter projects can access and use the same database simultaneously?
Edit:
The client project would mostly just query the database for results, whereas the admin project would be full CRUD.
If indeed creating multiple projects would be the recommended way to go, the admin project would be running on a sub-domain i.e admin.example.com whilst the client project would be running on example.com
It is valid to use any of the approaches you mention. It is a matter of personal preference (read: opinion). I have used each singly and in combination with more or less the same outcome. I have settled on using none of the above. Instead, I use a single project, no HMVC, no subdomains, standard CI file structure. I feel keeping it simple ultimately makes it easier to build and maintain. YMMV.
What separates the public-users from admin-users is authentication and authorization (A&A). Nobody gets into an admin controller without the proper login credentials and permissions. You're going to need A&A anyway to keep the public from accidentally discovering the admin area. IMO, a "special" file structure and subdomains actually make implementing A&A harder.
Depending on your deadline for this project you might want to look at using CodeIgniter Version 4. It's a thoroughly modern revamp of the framework. It is still in beta test mode, but I've found it to be quite stable. They are working hard to get to the release version. There is no published release date yet, but all indications are it will be sooner rather than later.
The answer as to how to configure CI is really dependent on your needs and what you feel is best. There is no right answer or "acceptable" way of doing things in this regard.
When I first started with Codeigniter, I had just a sub-folder for backend controllers called admin as well as an Admin base/core controller that all admin classes extended rather than CI_Controller. Models/views can be similarly organized in to sub-folders. This was a perfectly acceptable solution in my opinion for small-scale applications.
I moved in to HMVC and found that it really isn't that much different in terms of keeping them both separate. Although you can easily drag-and-drop modules from different projects so long as they are decoupled, you'll still have to jump through hoops to get front/back ends separate. I believe I used this is a starting point: https://github.com/jmtolibas/HMVC-CI3-with-Separate-Backend-and-Frontend
In terms of what you mentioned, having 2 separate projects wouldn't necessarily be a bad idea. You could even share the same system folder with a modification in index.php regarding the system path. Multiple database connections shouldn't be an issue.
So basically, all 3 approach will work, it is up to you to determine which one you like working with the most.
If you want my opinion, I would use Laravel or Lumen on any new project, and separation of front/back end is rather easy with packages, namespacing, .etc.
I have a database that I would like to be used by (n) number of applications.
This database sits behind a Webservice - So all CRUD operations call the respective webservice methods.
I will use a ticket based application as an example, although I'd imagine this could be expanded to most types of applications.
Let's say Site A - Is a site where tickets and events can be displayed and sold. Also Site A allows Authorized and Authenticated Users to add/remove events and tickets.
Let's say we also have Site B - Site B can only display and sell tickets and events. It cannot add or remove tickets and events.
Both sites are using the same database and webservice.
My question is - Is this a viable approach that will scale well? Is the single database a wise approach?
I don't understand what is the difference between "sell event" and "add event". The typical approaches for database scaling are:
Separate read and write calls. Write to single DB, read from multiple replicas
Separate entities to different databases. For example, store events in one database and tickets in another one.
Single database is a fine solution for a lot of applications. My suggestion is not to spend to mach on scaling at the beginning of your project, but keep in mind some ways how to scale it if required. It is nice that you have a single frontend to your database - in future you can add some logic there (like DB replication etc) and websites will use the same API without changes.
We are designing our new product, which will include multi-tenancy. It will be written in ASP.NET and C#, and may be hosted on Windows Azure or some other Cloud hosting solution.
We’ve been looking at MVC and other technologies and, to be honest, we’re getting bogged down in various acronyms (MVC, EF, WCF etc. etc.).
A particular requirement of our application is causing a headache – the users will be able to add fields to the database, or even create a whole new module.
As a result, each tenant would have a database with a different structure to every other tenant using the system. We envisage that every tenant will have their own database, rather than sharing a database.
(Adding fields etc. to the system will be accomplished using a web interface).
All well and good, but the problem comes when creating a data model for MVC. Modifying a data model programmatically to add a field to a table seems to be impossible, according to this link:
Create EDM during runtime?
This is a major headache for us. Even if we don’t use MVC, I think we’d still want to create a data model (perhaps for used with LINQ to SQL).
We’re considering having a table with loads of fields in it, and instead of adding fields to the database we allocate an existing field in the table when the user wants to add a field to his form. Not sure I like that idea, though.
Of course, we don’t have to use MVC or Entity Framework, but it appears to me that these are the kind of technologies that Microsoft would steer us towards for future development.
Any thoughts? I’m assuming that we’re not the first people in the world to consider this idea of a user-customisable application.
I'd make sure that you have fully explored the option of creating 'Name-Value Pair' type tables as described here http://msdn.microsoft.com/en-us/library/aa479086.aspx#mlttntda_nvp
before you start looking at a customizable schema. Also don't forget that you are going to have to grant much higher permissions to your sql accounts in order for them to create tables on the fly.
A customizable schema means that your sql accounts will also need much higher permissions. It wouldnt be advisable to assign these higher permissions to a tenants account, but to a separate provisioning account which can perform these tasks.
Also before investing effort into EF - try googling 'EF Vote of No Confidence'. It was raised (i believe) mainly in reaction to earlier versions but its definately worth reading up on. nHibernate is an alternative worth investigating.
Just off the top of my head it sounds like a bad idea to allow users to change the database schema. I think you are missing a layer of abstraction. In my mind, it would be more correct to use the database to hold data that describes the format of a customer's data. The actual data would then be saved in a text column as xml, including version information.
This solution may not fit your needs, but I don't know the details of your project. So just consider it my 5 cents.
Most modern SQL databases today supports the 'jsonb' type for key/value storage as a field. Other types (hstor for postgres) exists too. Forget about XML, that's yesterday and no application with respect for itself implements XML unless it is for importing/converting old data.
My team is in the process of designing a domain model which will hide various different data sources behind a unified repository abstraction. One of the main drivers for this approach is the very high probability that these data sources will undergo significant change in the near future and we don't want to be re-writing business logic when this happens. One data source will be our membership database which was originally implemented using the default ASP.Net Membership Provider. The membership provider is tied to the System.Web.Security namespace but we have a design guideline requiring that our domain model layer is not dependent upon System.Web (or any other implementation/environment dependency) as it will be consumed in different environments - nor do we want our websites directly communicating with databases.
I am considering what would be a good approach to reconciling the MembershipProvider approach with our abstracted n-tier architecture. My initial feeling is that we could create a "DomainMembershipProvider" which interacts with the domain model and then implement objects in the model which deal with the repository and handle validation/business logic. The repository would then implement data access using our (as-yet undecided) ORM/data access tool.
Are there are any glaring holes in this approach - I haven't worked closely with the MembershipProvider class so may well be missing something. Alternatively, is there an approach that you think will better serve the requirements I described above?
Thanks in advance for your thoughts and advice.
Regards,
Zac
It's been 6 months since the question was asked and no one seems to have been able to provide an answer so I thought I'd explain the solution we eventually chose.
Basically, we have decided not to use any implementation of the MembershipProvider - instead we use our own custom Membership Service sitting atop a repository. It was important for us to maintain the existing aspnet_Membership database so our repository has basically duplicated the built-in SQLMembershipProvider functionality (at least, the aspects we need of it) - initially via Linq-to-SQL but now we're transitioning to NHibernate. The plan is to replace the membership database in a year or so when all of our websites are upgraded to use the new model.
It was possible to use a custom membership provider but in the end it became apparent that it was simpler, more consistent, and more maintainable to use a custom implementation. We are still using the built-in forms authentication functionality for verifying that a user is logged in and for redirecting users who try to access secure areas of our site without first being authenticated - but we have overridden the functionality that is tied to the profile provider.
Ultimately, our feelings on this are that while the membership provider is a powerful and easy-to-use tool within ASP.Net, if it doesn't fit with the wider approach used in your application, it is worth considering an alternative approach.
Interesting, thanks for posting your final solution. I am in a similar situation, but writing a custom Membershipprovider. I don't know where to put the provider because it needs access to the DB as well as System.Web namespace. It seems like it's the one class that violates this whole separation of concerns design.
Having used some PHP frameworks such as Codeigniter and Kohana for some smaller sites, I'm starting to wonder if MVC is still applicable for larger projects and, if so, what precautions need to be taken to maintain clean clode. What practices do the larger sites use in order to prevent this? Does Amazon's or Flickr's code use MVC or some variant of it? Is there a guide that, given a certain problem, shows you how best to implement MVC for large projects?
-- Tangent --
On a current project using Kohana, I started to question what role my models should have. Often times, a model can only describe a small part of an object that I'm trying to build. I.e., need an object for a User, so I extract my user from the Users table using my Users_Model. But each user also has several items in their inventory, so I need to also use the Users_Inventory_Model. But, each inventory item also has other tables associated with it, and so on, until I find that building up a single User in my controller has required me to access several models. Now, imagine doing this in many different controllers and suddenly I find myself with messy and redundant code and very fat controllers.
This led me to think that maybe I should have libraries which handle most of the grunt work. That way, I could have a Users library and let it load all of my pertinent user data and run most of the logic such as updating, deleting, etc. Is this the way most MVC projects evolve? Letting libraries do most of the interaction with the models, while the controllers call the libraries and prepare the data for the views? Anyway, this is just one of the questions I've had about MVC, which I haven't been able to find an answer to online.
In fact, it's for big projects where all these MVPs and MVCs really shine. All software design patterns are "created" (besides establishing common vocabulary) to deal with complexity of software. Thus, used properly, MVC will be of great help to you in big projects.
Contrast with small apps, which can be hacked together with mouse-only approach, but are a nightmare to support since there's no proper separation nor they're SOLID enough.