1

So I get the concept of ViewModels, in particular the security issue, where you want to restrict the controller capabilities to the reduced set of fields in a ViewModel (as the typical User model, where the ViewModel has no information about passwords and roles).

Assume a ViewModel deriving from different Models, how would one correctly implement this (keeping e.g. the security thought in mind). Here an image that depicts the issue

enter image description here

I could imagine, that it is better to derive from "Sub-ViewModels" rather than directly from the Models themselves. Is there a best-practice way to do this?

rst
  • 2,510
  • 4
  • 21
  • 47

2 Answers2

1

No man, the whole purpose of a view model is to model the exact data you need for a view, nothing more, nothing less. It's not really a security issue, I mean, if you were to be storing things like passwords and stuff in the viewmodel than your doing wrong on such a level I've never seen before. ViewModels main purpose in the mvc framework is to allow you to pack and unpack multiple models and extra properties in order for your user to be able complete whatever targeted action they need to complete without giving them the impression they are drinking from a firehouse. I guess it has some "security" standpoints as you don't need to pass full models but just because something is included in the view model doesn't mean that you have to actively output HTML for that property. Most of those actions should occur server side anyway or in razor checks that generate the HTML.

If you are overlyconcerned about security and your controllers then you should look into 3 tier architecture anyway.

Travis Acton
  • 4,292
  • 2
  • 18
  • 30
  • That is exactly what I meant, that I don't want to have passwords in the viewmodel. The question was, if I combine two models with delicate information, shall I use viewmodels inbetween or not. – rst Jul 04 '17 at 04:12
  • What could you possibly gain by doing this? Let's simplify this. Let's say you have a user model that contains id, username, password, DOB, nickname. You also have a second model called userPreference that contains id, userid(ref to user model), favoriteIceCreamFlavor, SSN (because it's an example). You want a screen where the user can update their ice cream flavor and nickname so you create a new viewmodel that contains userid, nickname, favoriteIceCreamFlavor. You have access to the target fields you want to update and a means to reference all your data for an update via the userid. – Travis Acton Jul 05 '17 at 17:55
  • Let's take that a step further and say that only users who social starts with '123' can update their favorite ice cream flavor. You add SSN as a nullable type to your view model. With razor syntax in your view, you write an if statement to show an editor for ice cream only if ssn starts with 123. This is all happening server side, when the html is produced and sent as response, there is absolutely no trace of SSN anywhere on the page, in the session, nowhere. The user cannot get the data because you didn't set it into a variable or element that is passed client side anywhere. – Travis Acton Jul 05 '17 at 17:59
0

See the following:

ViewModels in MVC / MVVM / Seperation of layers- best practices?

A ViewModel is just that most of the time. What do you want the user to be able to View. Generally a ViewModel will be re used in a set of pages, but could be limited to just one or two.

I have many times inherited projects with a ViewModel for each page. It doesn't necessarily have to match up with your complex model. There is a host of information you might not want to pass into the view for various reasons.

I find there is much use in creating a base Controller and inheriting common functions for each custom ViewModel / Set of ViewModels.

lloyd
  • 1,089
  • 1
  • 17
  • 39