I'm contemplating using AFTER INSERT, DELETE, UPDATE Triggers to capture changes to one of my databases. One thing I want is to capture name of the user who made the change.
Since I'm using a dedicated SQL account to connect to the database (from ASP.NET MVC), I don't believe SUSER_SNAME() will provide accurate information to me.
Is there anyway for me to feed in the username from ASP.NET MVC side to the trigger?
ASP.NET side is configured for Windows Authentication against Active Directory.
Take a look at Set Context_Info. I've used this successfully in the past when auditing and using sql authentication. The idea is that you set the in the context the logged on user, then in the DB Trigger you retrieve this info from the context and store it in the DB. If you forget to set the user in the context, you can always fall back to suser_name (although, not very useful for auditing, but can be useful when making changes directly in SSMS). Google "Audit Trail Set Context_Info" and you will find some examples.
Like this one and this other one
You could use Thread.CurrentPrincipal to get the Windows Account and pass this as a parameter to your queries, and therefore, available to Triggers.
var userName = Thread.CurrentPrincipal.Identity.Name;
Related
ASP.NET MVC and Angular based enterprise web application is hosted for external users access. We encountered a scenario like an user can manipulate the values shown in the disabled fields and submit so using the browser developer tool. e.g. (1) Input field of Vehicle Name, description etc. is disabled in the edit mode, but user can set the read-only field property to editable using dev tool and manipulate the actual value to something else.
similarly, e.g. (2) Customer details are fetched by ID from Cust db and shown on the screen. The customer details are expected to be saved in another db with a few more inputted details, but user edits the read-only customer fields using dev tool and submits.
As a solution, introducing a server side validation between retrieved and sent back values on every submission does not seem to be a right approach.
So, how to protect the read-only or static values from manipulating with browser or other dev tools?
As a solution, introducing a server side validation between retrieved and sent back values on every submission does not seem to be a right approach.
Contrary to what you appear to believe, that is the solution.
You cannot prevent the user from crafting their own HTTP request. You cannot prevent the user from hitting F12 and sending you garbage. It is up to you to validate whether the user is allowed to update the data they send you, and whether they are allowed to read the data they request.
Client-side validation is being nice for your users; server-side validation is an absolute necessity.
I have been learning how to use ASP.NET MVC4 and have been getting my head around authenticating users and user roles and posting data using the entity framework to SQL.
However I have not been able to find any guides/resources (maybe I don't know the correct term) for posting and retrieving data that is unique to an specific user. For example how would a user only see the entries that they created if it was a site that stored data that is personal to each user.
What patterns/designs does one use when trying to do this?
Creating a sandbox of data for a specific is usually tied to authentication. You can access this many ways through ASP.Net.
First of all, every user gets identified even if they never log in. They get a session identifier. It essentially creates a small place in memory for this user where you can store any user related information. Think of Sessions as walled gardens for each user.
Session["UserFullname"]
This works, but realize Session is limited by time, so it is very volatile. Utilize it, but don't depend on it.
The next method is to authenticate a User. This is done using Cookies, but usually handled transparently for you by ASP.Net Membership or other authentication providers. To access the authenticated User you just need to use a simple line in your Controller actions.
// User is the property
User.Identity.Name
Both these methods can store information about your user that you would use to query data specific to them.
Select * From Orders Where UserId = *User.Identity.Name*
Note that both Session and User are accessible through HttpContext.Current as well, as long as you are in a web environment.
HttpContext.Current.User
HttpContext.Current.Session
You won't need to access them this way unless you are not inside your Controller, or inside of another class that doesn't already give you access to the HttpContext. I don't recommend this way either, since your code could be used outside of a web application where HttpContext is not available.
I hope that makes sense, and please feel free to ask me questions.
This is not so much about mvc, but more about the problem of relating data to a specific user. You have to ask yourself, how would you identify a piece of data to a user.
The way you would do this is to tie the data to the user in the data store somehow.
In a relational database you would do this by having a User table and using the unique key on that table to insert data into another table such as Order. Order would then have a User Id.
When a user logs in, you could store that ID in session and use that to filter out orders based on the id.
Im new to WF and i'm trying to build an asp.net MVC web site with several WF "wizards". All users will be logged in using forms authentication. The users will have many different WF workflows they can start and come back and finish at a later date. I've added an SQL persistence store to store the state of the workflow which works so far. However it seems to me you need to know the guid of the workflow in order to reload it and carry on.
Is there a way i can add the users username to the persistence so that i could list the users currently active work flows so they can carry on where they left off? Each user could have several active work flows at any one time.
The persistence store supports Persistence IO Participants which can supply values to be persisted along with the workflow. The code is a little tricky but there are samples available, just look for PersistenceIOParticipant.
I am porting an application from wpf to asp.net mvc.
In the wpf I have a view in which the user selects from a combobox the name of a client and then in some textboxes, next to the combobox, some specific information about the client will show up (email, address, etc). In wpf I fill all this information in an observablecollection that resides in memory and when the client changes, I retrieve the other ones from the collection so it won't fo through the database.
Is there any way in asp.net mvc I can do this ? Or every time the client changes i will fetch from the database the extra information ? (will be slow)
This controls is just to select the client (and the extra information to help the user) so it should be fast.
How would you do it ?
If you don't want to make a call back to the server for every selection, then you should look at a solution whereby you pre-fetch all the data that you need and hold it in a javascript object. Then you could write a javascript method that would fire on the selection DOM event.
Sounds like what you are looking for is Session. You can pull the list from the database once, store it in session, and then reference session as needed for each client's data. This recommendation is based on presumption that the list is not being modified elsewhere, and therefore, invalidating the version of the list you have stored in Session.
Using Session in ASP.NET - http://msdn.microsoft.com/en-us/library/ms178581.aspx
I have been thinking for a good while about how to tackle the problem of implementing an ID based user system while using ASP.NET MVC. My goals, much like StackOverflow's system are as follows:
Allow the users to change their nicknames without the "avoid duplicate" restriction.
Allow the users to authenticate via OpenID (not with password for the time being).
I wanted to avoid as much rework as possible, so I at first thought of using the membership, role and (perhaps) profile providers, but I found they were username based.
I thought of adapting the hell out of the SqlMembershipProvider, by using the username field to store the IDs and throwing UnsupportedException on password based methods and the like, just so as to be able to use the other systems. But it feels unwieldy and kludgy (if possible to do at all).
On the other hand, maybe I should roll up my own user system, but I'm not sure if even if I can't use the providers, I can still use some of MVC's features (plug my code in with MVC somewhere, I can think of AuthorizeAttribute off the top my head).
So I was wondering if anyone had run into the same design problem, and what solutions they had come up with.
The more detail the better!
I had to set up a quick membership system for a client, they had some requirements that didn't allow me to use the built-in right off the bat nor the time to build what they wanted. I have plans to eventually roll-out a complete membership management system, but like you, I needed something now. I went with the following plan, which will, eventually, allow me to swap out the built-in providers for my own - time constraints and deadlines suck:
I have my own Personal User Table (PT) - MembershipId, UserName, Email, superflous profile info. This is what the app uses for any user information. It's a class, it can be cached, saved in the http context, cookie - however you want to handle your user info.
I then set up the SqlProfileProvider for authentication, authorization, and roles. I don't use the profile provider (even for trivial settings) because it's a pain in MVC. I made no changes to the built-in providers. This is what I'm using for authentication and authorization.
When creating a user, my code does the following:
Check PT for user name and email, per my rules
Create Guid - MembershipId
Create MembershipUser, the MembershipId is the username (the email is irrelevant and not used), and user password, question and answer, etc.
Create the user in PT with the profile values and use MembershipId as the PrimaryKey.
On login, I get the MembershipId from PT, validate against Membership with the MembershipId and the password and I'm done..
When deleting a user, I do the following:
Check PT for user, make sure I can/should delete
Get MemberShipId
Use a transaction
Delete from PT
User Membership.DeleteUser(MembershipId, true) - this ensures that the user is deleted from teh membership and other aspnet_ tables
commit
And it works as expected :)
A few things:
User.Identity.Name will be the MembershipId (Guid). This is used for SignIn and Role management. My PT is where the user's info (save the password) is saved. I can change user names, emails, etc with no impact on Membership or Roles because Membership is based on the PrimaryKey from PT.
The signin requires an extra DB hit because you need to query PT to get the MembershipId to validate against (you could cache).
The built-in auth system is really heavy - if you look at the sprocs you will see all the hoops it goes through to validate a user. I'd recommend eventually getting away from it. But in a tight spot, it does a good job - and if you don't have a milion users, I don;t think it'd be a problem.
I didn't consider OpenId and I'm not sure how you would integrate it, although I think you could probably do the same thing as above and instead of validating against actual credentials (after they come back validated form OpenId) just log in the user using the MembershipId (don;t validate against Membership).
For me, the main point behind this was that the app uses a custom user model, allowing for changes to user name, email, names, etc. Without impacting the auth and roles. When I am ready to change to the complete system, I can change it without worrying about the impact to the app.
Kenji,
I would recommend looking at some of the existing OpenID providers for ASP.NET. It should be fairly easy to make them work with MVC.
Erick
Forgo the use of SqlMembershipProvider. The only thing it would really offer you is an out of the box admin interface. The rest that it brings would be a nuisance.
Just use the sql membership provider and add a stored proc to change the username at the database level.