I'm auto-generating a form in my ASP.NET page. This is already tested and working. I want to know if:
If there are any security problems with storing the database ID as part of my controls ID? I can see think of 2 issues: the id will be visible in page source (not really important in this case), and the possibility someone could change the name of the control somehow? This second possibility is more serious. Is this a potential problem and how to void it?
If there would be a better preferred way to associate a unique data with any type of control? Is it possible to store a custom item in the viewstate for the control?
You can create your own custom controls, inheriting from TextBox, for example. Create properties that store data in the ViewState. That is the fastest and simplest way for me to achieve the result you're needing.
just save them in the viewstate
viewstate["DB_ID"] = datarow("ID")
You can use hiddenfield. Or best way is store your ID in Session. Sessions are really secure.
don't store anything database related in your page. you are giving people knowledge of your system that should be hidden from view.
if you must store a database id, store it in the session or put it into your web.config file.
There's nothing wrong with using a database ID in a page. Just look at the URL of this page or nearly any other MVC-style site. It is not a security risk in itself unless your system is vulnerable to SQL injection attacks - and if it is, then you have bigger problems to worry about.
Related
Thanks for any thoughts. This question refers to an ASP.NET 4.0 web application.
A DetailsView then uses an ObjectDataSource (although any solution should apply to any of the ASP.NET DataSource controls) for CRUD operations.
A user has permission to view details for all records, but can only create or modify a single record related to their own department.
obviously I can easily modify the listview to show/remove the appropriate buttons
if (!_canModifySelectedWard)
{
dptDetailView.AutoGenerateEditButton = false;
dptDetailView.AutoGenerateInsertButton = false;
dptDetailView.AutoGenerateDeleteButton = false;
}
but this is only removing the buttons. Is there a neat way to disable the ability to edit/insert/delete functionality? I think a malicious request is highly unlikely once the user has access to this page, but it seems better practice to remove functionality, not just UI elements.
I can set the associated objectdatasource's InsertMethod etc. to null, but this almost seems like a hack.
Your object data source is tied to an class which is responsible for providing the data requested by the object data source. This is where additional checks should be performed to ensure unauthorized access to data doesn't happen.
Hiding the buttons is a good idea from a user experience perspective, but you should always make sure your business rules are being enforced.
Sorry I cannot provide any more detailed help. Perhaps if you could describe what you have going on in more detail, or post some code that would help.
Cheers.
After data is entered on a web form and then comitted to a database or whatever, what is the best way to clear the contents of the various text box controls and return combo boxes to a non-selected state? I know this can be done from the code behind but is not the best way since it requires a round trip to the server. I know javascript is also an option but I am not very familiar with it at all so is there another option or is Javascript the best way?
Thanks
Note: I'm making an assumption that you are doing a post back to the server in your form to save the data to begin with.
After you've processed the form (i.e. saved the data to the DB) why don't you clear the controls from the page and call "CreateChildControls". This would be the quickest way to clear your input controls before rendering the page back to the user.
YMMV, this isn't necessarily the best or safest way to do this but it can/could work; however I've only used this in custom controls that did not have a corresponding ascx file.
Hai, I have an ASP.NET page with 150 controls and i want to transfer data of these controls to another ASP.NET page. what method would be best for this task? Number of controls may increase.
Thanks in advance
There are many ways:
Using a Query String (Might not work in your case, only good for transferring small amount of data)
Getting Post Information from the Source Page
Using Session State
Getting Public Property Values from the Source Page
Getting Control Information from the Source Page in the Same Application
Its always preferable to wrap the data you want to transfer in an object and pass it using pt. 3 or Pt. 4 , though in case you have arbitrary number of controls, Pt. 5 may work better for you.
This should cover it comprehensively:
MSDN: How to: Pass Values Between ASP.NET Web Pages
ASP.NET 2.0 : Accessing controls in Previous Page
You can use datatable , populate the contents in the row and send it using session
Another way is use generic class and transfer it using session.
You can also transfer it using below mentioned code
TextBox previouspagetextbox = (TextBox)PreviousPage.FindControl("currentpagetextbox");
the above mentioned code will be written in the another page where you will access the controls of previous page.
Multiviews is an another option. So you donot need to transfer the contents. It will facilitate you in same page.
As i could understand your need it will be possible through server side session or any other servers side storing mechanism like you can store the data in the database also and then fetch the control values on the next page by the Primary key or any other composite unique combination but at the cost of your page performance i will suggest you better to use ASP:Wizard control that is available from asp.net 2.0.
Most of the things will be taken care by the asp:wizard and it will be easy for the user of the page to fill up the information in the controls.
for details ion wizard control read on the following link
Hope it will be helpful.
Happy coding.
You can use Server.Transfer('NewPage.aspx', True) to redirect to a new page and that page will have access to all of the controls that were on the previous page.
MSDN Article about it
The problem that I am having is as follows:
I currently have a custom class that generates buttons and places them on a placeholder on a master page.
The events for these buttons put specific values into session that differs values for a database query. In essence, the buttons serve as filters for charts.
After creating all the buttons, I realized that session values will stay constant from page to page, so everytime a user enters a different page while another is open, the filters selected on the open page will remain constant for the new page that is opened.
At first, I wanted to use viewstate rather than session, but then realized that a master page and a content page do not share the same viewstate.
At the current time, I am thinking of using a prefix for the sesson key that will identify what page the filters actually exist for. However, I am not wanting to overload session with numerous values if the user wishes to have many pages open at the same time.
Any solutions that would entail a way to share viewstate (or some other way to store values) between app_code, the master, and the content page?
Use HttpContext.Current.Items, it is a key-value pair collection with a lifetime of a single Http Request.
Have you considered Context.Items?
How many filters are we talking here? Store the filter values in the URL. Have you seen some of the URLs that google or an ecommerce site uses? They are quite long. Here is how I do it:
I store the filter values in the query like, www.chart.com?filter1=val1&filter2=val2 etc.
I user JQuery's query plugin to manipulate the query on the client side, and then request the chart from the server again, using the new query.
This way, I'm not junking up session, cookies, or anything like that, and if the user wants to store a bookmark to a particular chart or email it to a friend, they can and the filters are preserved.
I'm starting to think the answer shown in the following question will work:
ViewState object lost in Master Page Load
Exposing the desired variables via a property.
If the data isn't too long, cookies are a typical solution.
Another option is to use Silverlight isolated storage. The Silverlight control itself could be invisible (no UI).
I've been tasked with converting an existing ASP.NET site from using InProc session management to using the ASP.NET State Server.
Of course what this means is that anything stored in the Session must be serializable.
One of the most complicated pages in the app is currently storing an ASP.NET control collection to the Session. This is failing miserably because the controls cannot be serialized automatically.
Short of totally rewriting how the page works to prevent the need for storing the control collection in the Session, does anyone have a trick/solution for making the collection serializable?
Rewrite the page. You'll thank yourself later. There are sure to be other problems if the original "programmer" (and I use that term loosely here) thought it was a good idea to store a control hierarchy in session.
Don't store control collections in session state. Tess has a lot of articles about this, for example this one.
The first answer that comes to mind is to do a partial rewrite (I don't think there's going to be an easy answer to this). If it's a small number of control types, write your own controls that inherit from those controls and also implement ISerializable. Then, using search and replace, replace the page's controls with your versions. If you are using a large number of control types, you might spend more time extending the standard types than you would refactoring the page.
The work is going to be in the serialization and deserialization of the controls when you initialize them, to make sure you're capturing what you need (the TextBox values, the IsSelected, etc.).
This is obviously a hack, but if your priority really is not rewriting the functionality of that particuar page, this might work for you. Then, of course, you need to add this solution to the "technical debt" that your application is accruing, to make sure it's always on someone's radar to refactor at some point.