Let's say I have a class Person, with a string[] nickNames, where Person can have 0 or more nicknames stored. I want to create an asp.net page where a user can go and add/edit/delete nicknames.
Question is- how to i persist the Person object between postbacks? I query the DB and create the object then display it on a form, but then the user has the option to edit/delete fields of that object.. once the page is displayed with the fields of Person, how do I update that object with the changes the user made, to store to db?
Thanks!
Well if your Person Object is serializable you could store it in ViewState and if not, you could stick it in Session, but it sounds like you might have a general lack of understanding about Data Persistance in general
Depending on your implementation, and whether you're coding this all by hand or using the built in DataSource/DataAdapter controls, theres a bunch of ways to do it.
You could have a look at some basic ASP.NET/ADO.NET Tutorials to point you in the right direction
http://aspnet101.com/aspnet101/tutorials.aspx?id=17
Query the object it again (you could store it in a session variable but that doesn't scale), gather and apply changes from user upon postback.
Related
In an MVC application I have a two pages process. On the first page we gather information that will allow us to identify which database record to update. On the second page we gather new values used to update this record. In order for this to work, we need a way to persists information between the two pages, including some record id.
I though of two way to do this and both have some problem.
Store the information in the Session object.
This works as long as the user does not open a second browser window or tab. If he does there is a risk that he'll apply the modifications to the wrong record. Suppose he opens tab 1 and complete the first step. Record id 1 is stored in the Session object. The user then open tab 2 and complete the first step. Record id 2 is then stored in the Session object overwriting record id 1. The user then come back to the first tab and complete the second step thinking he is editing record 1, but in fact he will be editing record 2.
Store the information in an hidden field on the page.
This would solve the problem solution 1 has, but it would be trivial for a ill-intentioned user to change the record id to overwrite any record.
While typing this question I just though of a third solution. That is an hybrid of theses two, but I'm not sure it's completely safe. We could store a random id in an hidden field on the page and use this to prefix the key we use to access data in the session object. I think this would work. Could this be exploited as solution 2 could?
Any other good way to securely store data "per tab" instead of "per session"?
Considering way 2 you may check security server side. If a user does not have modification rights on a specific record then server must not save it. Otherwise he/she is modifying a record that has modifications rights on it and does not matter if he/she is doing it by standard UI or hacking under it.
I think you are mixing up two things - authorization and passing data.
If user is authorized to do stuff with "another record", it's not important if he "tempers the hidden", because he is authorized to change another record as well. Nobody is going to do that intentionally. Means - you just need to check if user is authorized to do stuff in every post from the user i.e. in each controller method (and this is normal practice to always validate all user input server-side).
I would suggest you go with "hidden field".
If you want to separate info in different tabs you should use sessionStorage that differs for each open browser tab.
You can set it like this:
sessionStorage.setItem("perTabValue", "true");
Then you can get your value:
var x = sessionStorage.getItem("perTabValue");
if(x === "yourValue"){
//do anithing you want
}
We created special form to creating purchase prices for vendors.
New form has almost the same fields as original (so we used PriceDiscTable), but the record/datasoruce was set as temporary table. After user filled mandatory fields will click button, (extra logic behind) and record will inster to database (real priceDiscTable).
The idea was to grand access to trade prices for users that not necessarily has access to purchase prices. In theory everything was ok, but when user with no access to PriceDiscTable open new form, error was shown "Not enougt right to use table 'Price agreements'".
We try set the AllowCheck to false in formDatasource but this only allow us to open the form, but user still cannot add or modify records.
Is there any way to force system to allow user to write data in the temporary table?
Disabling security key or grand access to real table is not an option.
Duplicate table and create with same fields is nuisance (if we use same table we can use data() method to assign fields)
I think that creating a new temporary table with [almost] the same fields would be the best solution.
If the only reason you oppose to this approach is that you wouldn't be able to use data() to copy data from one table to another you can use buf2BufByName() as described here: http://mybhat.blogspot.co.uk/2012/07/dynamics-ax-buf2buf-and-buf2bufbyname.html
You can use RunAs to impersonate another user...perhaps a system user. I don't entirely follow what you are trying to do, but it sounds like this solution would work for you if you know exactly what your custom code is doing and is capable of.
See Classes\AifOutboundProcessingService\runAsWrapper to see an example.
You will not be able to display the PriceDiscTable without giving the user at least "view" access or editing Classes\FormRun to somehow bypass the security key, which is kernel level so it's also not possible.
I agree with 10p where you should create a temp table and then create a custom method handler combined with buf2bufbyname() or buf2buf().
Another option you can screw around with, if you REALLY want to use .data() is using a Common as the datasource. You could add the fields you want on the grid with the common, then you can pass a common back/forth. This has a good amount of form setup to get this working, but it could produce what you want eventually I think.
static void Job8(Args _args)
{
Common common;
salesTable salesTable;
;
common = new DictTable(366).makeRecord();
select firstonly common where common.RecId == 5637145357;
salesTable.data(common);
info(strfmt("%1 - %2", salesTable.SalesId, salesTable.SalesName));
}
I have an object with multiple collections that is retrieved from a WCF service and stored in the session.
The collections are bound to ListViews on the page, with a final submit button at the bottom.
I want to be able to make changes to this object in the session (add/edit items in the collections), without persisting the changes until the final submit button is clicked.
The problem I'm having is that the ids are created in the db, so all newly added items will have an id of 0. I don't see a way to uniquely identify the collection items unless I add something like a clientID field to the datacontract. I feel like I'm missing something really obvious here.
If these are auto-generated identity values, you can insert additionally guids for each entry.
Objective:
To prevent users from tampering any id (example: CustomerId, UserId, ProductId, etc) between a round trip (from invoking HttpGet-handling to HttpPost-handling action methods), I want to use TempData[].
Most people,however, use hidden fields to keep track the ids. But I think users can still tamper them.
Shortly speaking,
Is using TempData["id"] safer than using hidden field for tracking an id between a round trip HttpGet and HttpPost?
Is there any disadvantage using TempData[]?
Edit 1
In this scenario, I use TempData[] only for tracking ids, not for other fields.
The other fields are still exposed to the users.
You should always validate user input and in this case make sure that whatever ID is passed in is actually the Id a user has access too. So is if safer? Not really because there is nothing flawed with hidden inputs if you do validation like you should anyway.
Using tempdata would mean you are accepting parameters from the routes ( presumably ) the HTML form and now TempData. That seems awfully complex instead of having real security inside of your controllers.
TempData also goes away after every request made to it. That means your Post methods will also have to populate TempData adding additional complexity.
From what I know TempData is stored in the session. Technically this is more secure than hidden fields (almost anything is) unless your session data is persisted in cookies. Then they are about the same.
If your session data is stored server side (say memory or database) then you are okay.
MVC 2 and higher, the TempData is only cleared when read. So you should be good for that.
Typically you'd expose the id in the URL and use permissions, validation, etc. to ensure that users are only accessing data (by id) that they really should be. If you really need to track data (say, through a wizard or a shopping cart) that shouldn't be on the page, then I'd suggest simply using the session explicitly.
I'm making a security permission system for a Dynamic Data site based on the article Securing Dynamic Data Preview 4 Refresh. The system contains an additional permission kind: "deny an operation for a record/field if a record is not owned by an user".
If an user can read only own objects, we need to have an always enabled filter in List and check permissions in Details. If an user can write only own objects, we need to check permissions in Edit and Delete, remove "Edit/Delete" links from some rows in List, make "User" field readonly and provide its value in Insert. I didn't think about column-level permissions of this kind yet.
So, the main problem, as I see at this moment: too many places to place the same checks (I didn't even think of malicious user crafting POST data). Also I couldn't make make a field in Insert at the same readonly and having a value which is displayed and saved to DB (I don't want to place that in the model partial classes because I think that there are already too many places that need to be edited to implement this functionality).
Is there a single place to deny a read or write operation with an object depending on the object value?
How can I provide a default value to the field, so that it will be shown on the Insert page, inserted to the DB and couldn't be changed by the user before inserting?
The following assumes you're using LINQ to SQL.
Is there a single place to deny a read
or write operation with an object
depending on the object value?
Reads
I know of no simpler way to restrict reads than to add a filter to all the relevant LinqDataSource controls. If you are able to implement your filter generally, you can write one QueryCreated handler, then add a single line registering your custom handler to all the page templates.
Writes
In the Dynamic Data metadata, add an OnValidate partial method to all the relevant tables. If the current user is not allowed to ChangeAction the given record, throw an exception. You will still have to update all the page templates to hide UI elements that the user does not have access to, but at least you can rest assured that the worst that could happen in some unexpected case is that the user sees an error page.
How can I provide a default value to
the field, so that it will be shown on
the Insert page, inserted to the DB
and couldn't be changed by the user
before inserting?
Perhaps look at some combination of adding an OnCreated and OnValidate partial methods. See also: this answer.