4 ms·

This. Set aside the performance of the initial load for a moment. When I interact with the SPAs we’ve built in recent years, I am still shocked how snappy they

This. Set aside the performance of the initial load for a moment. When I interact with the SPAs we’ve built in recent years, I am still shocked how snappy they are as I perform actions throughout the site. Every “pageview” requires the download of a tiny REST API response and comparably tiny HTML fragment. As a user - that experience is a pure delight compared to a full blown page re-load, re-download and re-render with every action. As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away. As a user I’m willing to pay a few more seconds upfront for snappy and seamless interactions as I use the app. I think the mistake that is more often committed (and where I myself as a user have less patience) is treating everything that can be accessed via URL as an “app”. If the user is coming to just download bytes, don’t build an app. An app is only justified when a user is coming to manipulate data.

samsonradu 9y ago
> As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away. I'm quite sure this is a sign of poor development, regardless of the form being validated on the server or the client. There is no reason for the server not to send back a fully pre-populated form.
- Can_Not 9y ago
  Credit card info, passwords...
  - naasking 9y ago
    You're already submitting it to the server. It's no less secure sending it back if there's a problem.
    - zbentley 9y ago
      This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad. Hash them securely (well, as securely as you can on the client side). Sending them twice is worse. Storing them with the session data on the backend so that they can be sent back to the client to repopulate a form is way worse, since more than one webserver may be handling a session, that plaintext data will have to be stored in a centralized database (e.g. memcached), which is really really bad, even if that storage is temporary. Some web forms get around this by just sending back the lengths of the individual fields so they can be masked when the form is repopulated, but that's less common and is something that doesn't occur to lots of developers (store the length, but don't send the whole string). Instead, it's easier to follow the mantra of "never store the passwords in plaintext, never send them over the wire in plaintext". Which is why most web forms clear out the sensitive fields when repopulated via the server. TL;DR it is much, much less secure to do this.
      - naasking 9y ago
        > This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad What are you talking about? Who said anything about plaintext? And no one said anything about sessions either. If you're submitting to the server in plaintext, then returning in plaintext is no less secure, but you're stupid for not submitting over https which is free. If you're submitting to the server over https then it's definitely no less secure to return the data.
      - samsonradu 9y ago
        Think you're a bit confused about how it all works. There is no need to use plaintext, we'll assume we're using https by default. You are already sending the data from the client to the server, I can as well echo it back with a couple of validation errors. I don't see the security hole in this situation, you do realise that regardless of the obfuscation you see in your password input fields, which by the way only protects from over-the-shoulder peeking, you are willingly sending data to the server and it will end up there unencrypted anyway. Otherwise there wouldn't be possible to do any operation at all.

samsonradu 9y ago

> As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away. I'm quite sure this is a sign of poor development, regardless of the form being validated on the server or the client. There is no reason for the server not to send back a fully pre-populated form.

Can_Not 9y ago
Credit card info, passwords...
- naasking 9y ago
  You're already submitting it to the server. It's no less secure sending it back if there's a problem.
  - zbentley 9y ago
    This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad. Hash them securely (well, as securely as you can on the client side). Sending them twice is worse. Storing them with the session data on the backend so that they can be sent back to the client to repopulate a form is way worse, since more than one webserver may be handling a session, that plaintext data will have to be stored in a centralized database (e.g. memcached), which is really really bad, even if that storage is temporary. Some web forms get around this by just sending back the lengths of the individual fields so they can be masked when the form is repopulated, but that's less common and is something that doesn't occur to lots of developers (store the length, but don't send the whole string). Instead, it's easier to follow the mantra of "never store the passwords in plaintext, never send them over the wire in plaintext". Which is why most web forms clear out the sensitive fields when repopulated via the server. TL;DR it is much, much less secure to do this.
    - naasking 9y ago
      > This comment displays a worrying misunderstanding of web security. Sending passwords (or credit card numbers or other scary stuff) in plaintext over the wire is bad What are you talking about? Who said anything about plaintext? And no one said anything about sessions either. If you're submitting to the server in plaintext, then returning in plaintext is no less secure, but you're stupid for not submitting over https which is free. If you're submitting to the server over https then it's definitely no less secure to return the data.
    - samsonradu 9y ago
      Think you're a bit confused about how it all works. There is no need to use plaintext, we'll assume we're using https by default. You are already sending the data from the client to the server, I can as well echo it back with a couple of validation errors. I don't see the security hole in this situation, you do realise that regardless of the obfuscation you see in your password input fields, which by the way only protects from over-the-shoulder peeking, you are willingly sending data to the server and it will end up there unencrypted anyway. Otherwise there wouldn't be possible to do any operation at all.