views:

14

answers:

0

Back in the day when we were mostly submitting forms from one page to another we used to have to validate all post parameters to make sure that the ids somehow belonged to the user that was currently logged in. After all you didn't want a "hacker" to be able to pull someone else's information. In modern ASP.NET application in a situation where a lot of these keys are part of server controls (ex DataKeys of GridView) and is stored in ViewState which is supposedly stamped with a hash that gets validated on every post back, does anyone still validate that the key that was retrieved in fact belongs to the user?

I currently do, my business layer methods tend to take an instance of a "profile" object that is maintained in session for each user, the profile contains all basic information including the company etc that the user is associated with. Having the profile in every business method I can validate that any piece of information requested by the web layer from the business layer does in fact belong to the user requesting it. Another thought is that the library (business layer) can also be reused outside of ASP.NET where perhaps the input would not be as secure. I am wondering if all of this is overkill as all of my basic GetSomething() methods tend to have extra trips to the database to make sure that an ID passed into the method somehow maps to the company specified in the profile. What do you do?