Does anyone have a view on whether to use a new separate database for forms authentication users, or is it ok to mix it with your application database?
I could see separation being useful if multiple applications/databases were sharing user authentication, but in my case I have one website/database, and intended to just add the tables/views/sps created by aspnet_regsql.exe to my current application database.
Any views/opinions welcomed. Thank you.
You can mix that db with your database BUT you should not make any changes to the default database tables if you want to use asp.net built in classes that use that database , It means you can only add your tables to that database !
That is OK to have a single Database from which the Forms are to be authenticated. Since the SQL server is a very secure one there will be no problem in having a single database.
But If you want to setup Your custom database for Authentication then Refer the following Links
Using Forms Authentication with a customer database
forms authentication with sql server 2008 database questions
Related
I have a database that I've created. I also have created a new ASP.NET MVC application using Individual User Account boilerplate code to get started. I notice that my web.config is pointing to a default location. I want to keep the boilerplate code and bring in my data model using Entity Framework so that. However user authentication tables and the tables I have created are in 2 different databases. What is the best way to resolve this?
Ultimately I just want to use the ASP.NET MVC authentication and bring in my data using Entity Framework and have both my data and the user account tables in the same database. If there is a better approach to doing this all together I am all ears.
You could create an attribute on each Individual User that has their own connection string so that every time you create a new db context, you do it passing their connection string attribute, then the context would be pointing to the correct database each time.
I use SQL Server and have a SSO Database that contain application role, and application permissions for several my organization applications. several web service created for this database and each application work with these services. I want to restrict my application to get only and only own data from SSO database. and can't view, insert, delete or change role and permission for another applications.
what's the best practice for this problem.
Can I use App_Name() or Program_Name() for this purpose.
thanks in advance
Don't give the app access to the tables, views etc, just make a well defined API using stored procedures.
I have an ASP.NET MVC 4 app. My database is hosted on Windows Azure. My solution has a new SQL Server Database project. I want to start off by adding adding the ASP.NET Membership functionality to this Database [project]. My question is, how do I do that?
I thought it would be a straight forward drag and drop operation. However, I cannot figure out how to do this basic task. All of the online videos I find demonstrate how to to implement the login via the ASP.NET MVC side. However, I don't see anything that shows setting up the Membership tables/sprocs/views and getting them in a SQL Server Database project.
Thank you for any insights.
You can get the script(s) necessary for adding membership to a database using aspnet_regsql in your framework folder (usually %windows%\Microsoft.NET\Framework\v4.0.30319\). An example usage for producing the .sql file would be:
...\v4.0.30319>aspnet_regsql -sqlexportonly MembershipScript.sql
From there, run that script against your database. You may also need to play with the -d <database> flag, but all options can be shown using aspnet_regsql -?. (This includes exporting the necessary tables for session state and other options).
I hope that's what you were asking but if I've misunderstood the question please clarify and I'll do my best to revise the answer
The template for creating an MVC 4 Internet application with forms-based authentication uses both the traditional ASP.NET Membership database with an additional layer on top called SimpleMembership, which has its own database. The SimpleMembership database uses Entity Framework code-first model which creates the database automatically the first time you start the application. Since SimpleMembership uses code-first the database schema can be modified by changing the UserProfile class in AcccountModels.cs. What is your objective for putting these databases that are handled by the application into a separate database project? Unless you are going to bypass SimpleMembership any solution will have to handle two databases.
I have a question that really feels like I should have an easy answer to, but for one reason or another I haven't been able to totally reason around it.
I'm embarking on development of an ASP.NET MVC3 intranet application, and I'm currently working on designing authentication & authorization. We're forced to use basic authentication in our environment, and we use Active Directory, so the authorization part is generally taken care of. Unfortunately our role/user hierarchy in active directory doesn't mirror what I need for the roles in the application, so I'm going to have to define my own.
I'm using SQL Server, so I was originally thinking of using stored procedures for all DML, and then creating roles and adding users in roles in SQL Server, and then controlling access to the stored procedures via those roles. I was also thinking I could query for those SQL Server database-level users & roles in order to use that as the source of authorization info in the application itself. That originally seemed like a great idea, but it doesn't seem like a popular one (for one, it seems the queries for that are a little long and messy for what they produce). Alternatively, would it be better to have the web app impersonate a user for all queries to the server, and then implement a user/role database with my own schema, and only authorize on the application side?
It originally seemed that authorizing on both the application and database side would be a good thing for security, and using the SQL Server user/role objects means that the user and role data wouldn't need to be stored in two places.
I did see some potentially relevant discussion at Best practice on users/roles on SQL Server for a web application, but I think this is a different question overall.
Thanks!
I recommend creating a sql login that the web application will use to connect to sql server. This way you are not impersonating any specific AD account which may get deleted, disabled in the future and can control the user strickly in SQL Server.
I would then recommend implementing roles based authentication in your application. This will enable you to create users and roles that are custom to your application and then assign users to them. This way if a user tries to access a resource that their role is not allowed it will not do any work. Here is a demo app based on this principle http://www.codeproject.com/KB/web-security/rolesbasedauthentication.aspx.
i am in a multi-user environment
i am using access as a front end connecting to sql server database. i am allowing users to edit only one table in sql server.
i dont want to continue using access to edit a sql-server table.
can someone recommend another tool to do this?
The Access 2007 runtime and the Access 2010 runtime is free for the download from Microsofts website. Of course you'd want to purchase Access licenses for power users who want to create their own queries usually for export to Excel.
Either Access or Excel are almost certainly the simplest solutions available that meet your requirements, when you consider both the simplicity of the user interface itself and the simplicity of implementing, deploying, and maintaining the solution for the users. Creating even a simple web page isn't nearly so simple – you'll need to setup a web server, configure user security, develop the web page, etc.
Use SSMS -- Sql Server Management Studio.
Update
Found a near duplicate #SU: Less daunting front end for SQL Server
Update 2
Try to use Microsoft ASP.NET Dynamic Data. And a tutorial on YouTube, of course.
Sounds like you need to give CRUD access to a table in a SQL Server database.
Suggest making a simple page - use ASP.NET Dynamic Data. Watch this video to get started with ASP.NET Dynamic Data.
Failing that, provision the user with Microsoft Access.
setup a new user in SQL Server, and give it permissions on that table only.
setup Access to read, update, create and delete that table. Use the credentials of the user in the bullet above. This will ensure they can't mess anything else up.
Only bring that table into the user's view.
If you pull down a copy of visual studio express you could build a single screen application that allows editing a table with just drag and drop from the server explorer. No coding needed unless you're looking to add some more advanced logic.
Alternatively you could just use Access to also build a one screen front end - with that as the start up form to your Access DB your users wouldn't even know they're in Access.
Edit:
Assuming you're in a windows domain - put all your users in to a security group and then grant this group access to the SQL Server. Only grant the group permissions on the specific objects that they need to edit.
Create a blank Access DB.
Link your SQL Server table in to the Access DB - e.g. in 2007 the option is in the External Data ribbon > more... > ODBC database.
Once you have the table linked create a form to edit the data by doing Create > more > Form Wizard.
This allows you to pick the exact columns you want them to edit, pick a layout etc.
From here the options are really only limited by how much effort you want to put in but it's a good start in contrast to direct table access.
I believe it's still in Beta but you might want to also take a look at WebMatrix.