Currently working on a web application in ASP.NET, MVC3 that allows people to view items, and change anything. This is with using my own database that I have created, but this I have found is good for generally viewing anything on the application but not good for security purposes to prevent them seeing particular things, and I do not want to waste my time removing tables and re-adding them.
So... Is there a way to communicate between the ASPNETDB and my own Database which would allow users to login to the web application but also sign up as a customer?
I would solve this using database roles, and only grant the appropriate roles to the user used to login to the two databases.
You have very granular control over what you want a db user to have access to.
Read up on databases and db roles
Related
I'm building my first MVC5 application for Azure and have tracked down all the parts and pieces I need to put it together (User accounts, scaffolding, roles, etc) except one. I need to have users placed in "workgroups" and each user in the workgroup can only see the data associated with that workgroup. For instance, if I have a simple Cars model, users in workgroupA can add/remove/change cars but only within workgroupA. Users in workgroupB would not see any of that data at all when they log in.
C# programming isn't an issue for me, just getting familiar with MVC5. I have previously accomplished this with Django and its built in group management, but need to move to MVC5 and can't seem to find an example that gets me close enough. Can anyone point me toward the best practices for this?
I must have missed this somewhere (or slept through the class)... the standard ASP security tool for managing users and roles seems to be absent when using the new simple security version. That is, the original is there and working, just points to traditional ASP security... NOT to the new "simple" system.
In my project I can log in, I can look at the webpages_ tables but can find no method of accessing them in my project... I would be happy to manage roles and get the USERID and maybe ROLEID so I could tie the user to other functions in my project.
I've looked through hundreds of posts and articles... normally I find I am missing some minor config entry or something but this time I am a little more stuck.
Advice is appreciated.
Thanks!
SimpleMembership does not work with the Web Site Administration Tool (WSAT). There is a good overview of SimpleMembership in this blog. Here is a quote from it.
WSAT is built to work with ASP.NET Membership, and is not compatible with Simple Membership. There are two main options there:
Use the WebSecurity and OAuthWebSecurity API to manage the users and
roles.
Create a web admin using the above APIs.
Since SimpleMembership
runs on top of your database, you can update your users as you would
any other data - via EF or even in direct database edits (in
development, of course)
I would also add that you can seed some of this information at application start-up, such as what roles are available, as shown in this article.
I am working on designing a web application for our customers where each customer has a unique portal into the system. Each customer needs to be able to manage their own set of users without concern for other customer's users, thus two different customers need to be able to both have a user jasonsmith.
At the same time, one customers show NOT have any knowledge of the other customer's existences, nor that this is a multi-customer system.
What are the standards today for implementing such a system? Where should I go to learn more about how best to implement such a system.
What you are talking about is called multitenancy.
There are several approaches to this.
Most common approaches are:
Single database
All tenants share the same database. You'll therefore have one tenants table with the information about all tenants. All other tables uses the tenantid as a foreign key.
The problem is that you have to make sure that the user only accesses it's own information (the user can for instance try to change the id in the uri). You'll therefore have to validate each object that the user has tries to access.
Multiple databases
Some database engines (like RavenDB) can handle several databases without a problem. That means that each customer get's its own database (which you load at the beginning of each request after the user have been identified).
So you'll have one db users during the authentication to be able to identify the tenant and one database per customer.
The upside with this solution is that it's impossible for the tenants to access each others database. (unless they've hacked the account)
I have a simple ASP.NET MVC + OpenID + NHibernate app (on top of MSSQL Server DB). The app is strictly single tenant and supports multiple users with only 2 roles (Admin and User).
I would like to convert this app into a multi-tenant app. My requirements are limited: I just need to introduce the notion of Accounts, each account having its own set of users and behaving exactly like the original non-multi-tenant app. There is no interactions between accounts.
What are the best practices to do this migration the most simple way? In particular, I am can manually update all entities and repositories with an Account_id field, and upload the logic too. But, I am wondering if there are no smarter approaches that would somehow abstract this aspect.
Ps: the app is very light, I do not wish to introduce a new DB instance for each account.
Probably the best thing I could think of is to embrace the Filter feature of NHibernate. It allows you to easily enable a filter on the query you're running and you can optionally enable them on tables that are setup to be multi-tenanted
I am creating an Asp.net MVC application and I'm currently using the built in Authentication/Authorization code that comes with the sample MVC app. For the most part this is working ok and I kinda understand what's going on.
What's concerning me though, is that now I kind of have my users stored in two different tables across two databases. i.e. I have users in my App's database that represent the "Customer" entity in the application, as well as the "User" in the Authentication database that's used to log in someone to the app.
Should I take the logged in user's User.Identity.Name value and do look up in my Customers table or should I merge them into one table? What's the best practice way of handling this?
Please forgive my ignorance - this is the first time I'm working with a system like this.
Any feedback is greatly appreciated!
It's helpful to think of credentials and the records that associate a person to application data as two very different things. Depending on the application, your Customer may not have credentials to log in or you may have an administrative User that logs in but isn't related to your application data.
Separate credentials are also useful if Users access more than one application with different rights for each.
For these reasons, I'd keep Customer and User separate and look one up from the other where appropriate.
You can extend the .Net Membership Provider to take all the information you want and post back in a single model I think.
See this one ASP.net Profiles and Membership - Custom Providers or should completely I roll my own?
And this one How to implement ASP.NET membership provider in my domain model