What most developers do is store an identifier instead of the actual sensitive data. For example, if you're updating an Employee (from the table Employees), each Employee might contain sensitive information like the tax identification number, salary, family
members, etc.
Instead, one option is to send a single hidden field containing only the employee id (which presumably isn't sensitive information). When the action executes, it reads this hidden field to perform an Employee lookup by number against the database. Now
the action has access to all of the sensitive information without having exposed it in the form.
If you go this route, you'll have to take some other precautions. For example, you'd have to verify that the person submitting the form actually has access to that particular Employee record (otherwise they could tamper with the EmployeeId field in the
form). You'll also have to
prevent over-posting if you're binding directly to an Employee object. (This latter point is why I always implore people not to bind directly to their database models, but instead to use view-specific models and map them to database models as necessary.)
Marked as answer by ricka6 on Dec 02, 2010 05:59 PM
levib
Star
7702 Points
1099 Posts
Microsoft
Re: How to get rid of hidden fields in ASP.net MVC 2
Dec 02, 2010 05:45 PM|LINK
What most developers do is store an identifier instead of the actual sensitive data. For example, if you're updating an Employee (from the table Employees), each Employee might contain sensitive information like the tax identification number, salary, family members, etc.
Instead, one option is to send a single hidden field containing only the employee id (which presumably isn't sensitive information). When the action executes, it reads this hidden field to perform an Employee lookup by number against the database. Now the action has access to all of the sensitive information without having exposed it in the form.
If you go this route, you'll have to take some other precautions. For example, you'd have to verify that the person submitting the form actually has access to that particular Employee record (otherwise they could tamper with the EmployeeId field in the form). You'll also have to prevent over-posting if you're binding directly to an Employee object. (This latter point is why I always implore people not to bind directly to their database models, but instead to use view-specific models and map them to database models as necessary.)