I'm trying to send the user id (integer) from a view to the action. If I pass it using routevalues object, the user id will be visible in the browser address bar.
How can I pass user id from view to the action without using aforementioned method??
You can use a hidden input element inside a form. You should generally use POST, not GET (i.e. use a form, not an a href) for anything that is changing data in your system.
The user id is commonly inferred from your authentication mechanism (cookie etc), so for the current user you shouldn't need to pass it around.
The main time you would include this in the request is when the page being displayed relates to users - and in particular where you (or an admin) want to browse other users records - then you might use "/users/current/orders" (use the cookie) or "/users/12345/orders" (and you should verify permission to browse 12345).
Note that if you use /current/ or similar, you should ensure it isn't cached between different users - so in many ways it is simpler to just show the user-id and to heck with the url; just go for the simple "/users/12345/orders" case.
What is the scenario here?
Related
Scenario:
(with an ASP.NET web app - Core or MVC)
I have a database with Users and Items for each user.
That means the UserId is a foreign key in the Items table.
From the browser I login as a User. I get my Items as a list of ItemViewModels, which are mapped (AutoMapper) to ItemViewModels via a simple api GET request.
I want to update one of the items (which should belong to me - the logged in user) via a simple API call. So I send the modified item back to the server via a PUT request as an ItemViewModel.
First approach:
The simplest approach would be to include the Item's database ID, ItemId, in the ItemViewModel - so when I receive the item to be updated as an ItemViewModel, I can map it back to the existing item in the database.
This however sounds pretty unsafe to me, as anyone could modify the PUT request with any ItemId and affect items which don't belong to the user who executed the request. Is there anything I'm missing about this approach?
Second approach:
Don't pass the database PK ItemId in the ItemViewModel.
Instead use an additional form of identification: let's say that user X has 10 items. And they are numbered from 1 to 10 using a property named UserItemId(which also exists in the database).
I can then pass this UserItemId in the ItemViewModel and when I get it back I can map it to an existing Item in the database (if all was ok with the request) or discard it and reject the request if the UserItemId didn't match anything from the logged in user's items.
Is anyone using this approach?
Pros:
The user only has access to it's own items and can't affect anyone else's since it doesn't know the actual Item ID (primary key), and any modifications are restricted to it's items.
Cons:
A great deal of extra management must be implemented on the server side for this approach to work.
Any other approaches ?
Please consider that the case mentioned above applies to all entities in the database which a client side implementation can CRUD, so it's not just the simple case described above.
The proposed solution should work for the entire app data.
I know this question has been asked here and here but the first one doesn't have a satisfying answer and I don't think the second one really applies to my situation, since it just deals with the UserId.
Thanks.
EDIT
Please consider the Item above as an aggregate root which contains multiple complex subItems each with a table in the db. And the question applies for them as much as for the main Item. That means that each subItem is passed as a ViewModel to the client.
I should mention that regarding further securing the update request:
For the first approach I can easily check if the user is allowed to change the item. But I should do this for all subItems too.
For the second approach I can check if the user can update the Item as follows: I get the userItemId of the incoming ViewModel -> I get all the logged in user's items from the database and try to find a match with the same userItemId, if I get a hit then I proceed with the update.
I think your application is not secure, if you only hide the Id.
You must check, before changing the database entity, if the user is allowed to change the entity.
In your case you should check, if your Id from the authenticated user is the UserId in your item.
If your ViewModel ist similar or identical for your API you could use a FilterAttribute in your controller.
I have one method which receive two parameters (int?, string). Action in my controller must save this variables and return view with form. After form is returned from client I need this variables from previous request. I can pass them to view with ViewBag and add to form as hidden, but it is very dangerous, anyone can change it in browser. Any ideas?
I think this question does not make sense.
If I have method which receives two parameters with HTTP GET method, so it's no difference where user change this two variables, in get method or in form.
If I store it in server side, he can change when passing parameters to first method and server will store wrong variables.For example:http://www.someurl.com/Controller/Action/?id=123&key=someKeyI can change parameters by editing url, so absurdly store it as variable at server side to make sure that user wouldn't change it by editig hidden fields. Moreover I can check if key is the same key as in database with this id.
Session time is 20 or 30 minutes. User can open this form and submit it when the time of session is out. Users don't like exceptions
It's pretty standard to allow forms to expire after a certain amount of time. You can keep sessions open forever as that's a security hole.
As for the actual value, you can remove it from the session as soon as the second page has been processed. If the value is not there when the second page is hit, simply redirect to the first one again and show a message that says that it took too long time.
Your second option is to use TempData with is specifically designed for storing values between two pages. TempData cannot be accessed by the user.
The third option is of course to store the value in a database (to keep it as long as you want, between logins etc)
You can store any object you like in the current session of the user. In your controller you can use:
// Save value to session
Session["MyVariableName"] = 32;
// Read value from session
int myVariable = (int)Session["MyVariableName"];
For more info regarding the session see: https://msdn.microsoft.com/de-de/library/system.web.httpcontext.session(v=vs.110).aspx
I have a simple view that displays some customer details in a list. The user can filter down the list using drop downs and text boxes to show results they are interested in and then JQuery/AJAX is used to return a partial view and update the list. For each item in the list there is an edit button which takes the user off to a different action to edit that specific item. When they save or cancel the user is directed back to the customer details page but the filters they had applied have obviously reset back to default. I was wondering what the standard way would be to tackle this seemingly common problem in the MVC world?
Thanks.
As HTTP is stateless protocol , it's your responsibility to remember the state of the page. One of the way we do is show the additional detail on clicking the Edit button on the same page in popup . It will solve the problem in case you are ready to make the design change.
Otherwise you have to use the standard state management technique , like Session or Cache on the Server to remember previous search state or you can append some key value in the URL it self and when user cancel , recollect the state from the URL query string .
One more way if security is not concern is using the Cookie to store the previous selection on the client machine if it is very specific to user.
Just use Session to persist their filters. It tends to be overused by inexperienced developers but the situation you describe is pretty much exactly what it is for.
One way is to fake the update of current row.
Consider, You clicked a delete button to delete the row.
Now with jQuery-
$.get(url,data,function(data){
if(data.success){
$('row').fadeOut(300,function(){
$(this).remove(); //<--- This is what I mean
});
}
});
Here you have removed the row on the basis of Json result and your page didn't need any refresh.
Also as in your case, Just load the edit Partialview at the same page by managing some space.
You can do this at least.
I am trying to conceive of a way to store a list of selected items to the session, for later use. I've googled and read examples for 2 hours now, and haven't found any examples that work.
The basic idea is this. User sees a list of items to act upon. User selects a number of them. User chooses action to perform. Controller takes list of selected items, and begins to act on them.
Am I thinking about this wrong? It makes sense to me to use an Ajax action to store the 'select/unselect' action on the session object. I really don't want an entire database object to handle this. I just want a simple list of selected objects. In classic ASP, I'd just have reacted to the selected items in a form post, but that doesn't seem right in asp.net mvc....
How do I construct this behavior (with or without the Ajax, but preferable without the DB access)?
I don't get it, why not bind directly an array of bools or something directly to your view's list of checkboxes? You can get them as parameters in your controller function and act upon them directly, with no middleman, they'd just be another POST value.
Or even better when you send in your list of items as part of your model, make them a structure that has a bool selected=false field that is bound to the checkbox next to the label, and you'll get the results back in your model directly.
I am using the Redirect After Post pattern in my ASP.NET MVC application. I have
the following scenario:
User goes to /controller/index where he is asked to fill a form.
Form values are POSTed to /controller/calculate.
The Calculate action performs calculation based on input and instantiates a complex object containing the results of the operation. This object is stored in TempData and user is redirected to /controller/result.
/controller/result retrieves the result from TempData and renders them to the user.
The problem with this approach is that if the user hits F5 while viewing the results in /controller/result the page can no longer be rendered as TempData has been expired and the result object is no longer available.
This behavior is not desired by the users. One possible solution would be instead of redirecting after the POST, just rendering the results view. Now if the user hits F5 he gets a browser dialog asking if he wants to repost the form. This also was not desired.
One possible solution I thought of was to serialize the result object and passing it in the URL before redirecting but AFAIK there are some limitations in the length of a GET request and if the object gets pretty big I might hit this limitation (especially if base64 encoded).
Another possibility would be to use the Session object instead of TempData to persist the results. But before implementing this solution I would like to know if there's a better way of doing it.
UPDATE:
Further investigating the issue I found out that if I re-put the result object in TempData inside the /controller/result action it actually works:
public ActionResult Result()
{
var result = TempData["result"];
TempData["result"] = result;
return View(result);
}
But this feels kind of dirty. Could there be any side effects with this approach (such as switching to out-of-process session providers as currently I use InProc)?
Store it in the Session with some unique key and pass the key as part of the url. Then as long as the session is alive they can use the back/forward button to their heart's content and still have the URL respond properly. Alternatively, you could use the ASP cache, but I'd normally reserve that for objects that are shared among users. Of course, if you used the parameters to the calculation as the key and you found the result in the cache, you could simply re-use it.
I think redirect after post makes much more sense when the resulting Url is meaningfull.
In your case it would mean that all data required for the calculation is in the Url of /controller/result.
/controller/calculate would not do the calculation but /controller/result.
If you can get this done thinks get pretty easy: You hash the values required for the calculation and use it as the key for the cache. If the user refreshes he only hits the cache.
If you cant have a meaningfull url you could post to /controller/index. If the user hits F5 calculation would start again, but a cache with the hash as key would help again.
TempData is generally considered useful for passing messages back to the user not for storing working entities (a user refresh will nuke the contents of TempData).
I don't know of more appropriate place than the session to store this kind of information. I think the general idea is keep session as small as possible though. Personally I usually write some wrappers to add and remove specific objects to session. Cleaning them up manually where possible.
Alternatively you can store in a database in which you purge stale items on a regular basis.
I might adopt a similar idea to a lot of banks on their online banking sites by using one-time keys to verify all POSTs. You can integrate it into a html helper for forms and into your service layer (for example) for verification.
Let's say that you only want to post any instance of a form once. Add a guid to the form. If the form does not post back and the data is committed then you want to invalidate the guid and redirect to the GET action. If say the form was not valid, when the page posts back you need a new (valid) guid there in the form waiting for the next post attempt.
GUIDs are generated as required and added to a table in your DB. As they are invalidated (by POSTS, whether successful or not) they are flagged in the table. You may want to trim the table at 100 rows.. or 1000, depending on how heavy your app will be and how many rendered but not yet posted forms you may have at any one time.
I haven't really fine tuned this design but i think it might work. It wont be as smelly as the TempData and you can still adhere to the PRG pattern.
Remember, with PRG you dont want to send the new data to the GET action in a temp variable of some sort. You want to query it back from the data store, where it's now committed to.
As Michael stated, TempData has a single purpose -> store an object for one trip only and only one trip. As I understand it, TempData is essentially using the same Session object as you might use but it will automatically remove the object from the session on the next trip.
Stick with Session imho rather than push back in to TempData.