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]
