I'm no expert in .NET bu have seen aplications killed with VIEWSTATE, one page had a viewstate of 75 kB, which means 150 kB of traffic per request.
I'm affraid this could break the "easiest way should be the right way". I hope someone with more .NET expirience could elaborate more on the VIEWSTATE issue. On 11/28/05, Danny Angus <[EMAIL PROTECTED]> wrote: > > Massimo Lusetti wrote: > > >I've to admit, as a global note, I'm not very comfortable with storing > > states (and consequently what relates to states) on the client > > I agree with Massimo, not only does bandwidth become an issue, but > security > becomes more of an issue as well. > > I'm not saying that it would necessarily expose a weakness, but it might > make it easier for less-experienced developers to inadvertently expose a > weakness. > > For example if it is possible to manipulate the client-side state, and we > have to assume that if we can do it then it is possible (if difficult), so > we have to ensure that every precaution is taken to ensure that we > validate > the state against allowable states for that user. In practice this is not > trivial, we have to identify the appropriate validation to use for each > application and set of data. The real danger of this is that we really > would be seeing a move to a less secure model. > > Lets look at an example; If the state recorded is an account number for an > account you are allowed to administer we can let you see your account > details, but how can be be sure that you are still the person who is > entitled to see that data? Obvious we make you log in (and http_auth > ensures that the browser sends your password with every logged-in request) > and compare the user we retrieve from the server with the one associated > with the client-side state, in our example we also have to verify that the > account is associated with a user you are allowed to administer. We will > pretty quickly end up wishing that we had a server-side state we could use > to validate requests against. Doesn't this defeat the purpose? I though > that the whole principle behind sessions and session-id's was about moving > state from the client into the server where it is secure and can't be > tampered with. > Is it not possible to split the state intellignently between client and > server? > > As far as bandwidth is concerned I'm quite sure that my employer would be > somewhat less than pleased if my new application consumed more bandwidth > than an equivalent older one, someone has to pay for bandwidth and its > often both parties, naievely put for a 100% marginal rise in traffic > between two parties you get a 200% rise in marginal cost. > > d. > > > > *************************************************************************** > The information in this e-mail is confidential and for use by the > addressee(s) only. If you are not the intended recipient (or responsible for > delivery of the message to the intended recipient) please notify us > immediately on 0141 306 2050 and delete the message from your computer. You > may not copy or forward it or use or disclose its contents to any other > person. As Internet communications are capable of data corruption Student > Loans Company Limited does not accept any responsibility for changes made > to this message after it was sent. For this reason it may be inappropriate > to rely on advice or opinions contained in an e-mail without obtaining > written confirmation of it. Neither Student Loans Company Limited or the > sender accepts any liability or responsibility for viruses as it is your > responsibility to scan attachments (if any). Opinions and views expressed in > this e-mail are those of the sender and may not reflect the opinions and > views of The Student Loans Company Limit > ed. > > This footnote also confirms that this email message has been swept for the > presence of computer viruses. > > ************************************************************************** > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > >
