4 ms·

Considering that code which runs client-side is untrusted ,your users could easily change it, how does one deal with security in "isomorphic JavaScript"? Is it

by phaer 12y ago

Considering that code which runs client-side is untrusted ,your users could easily change it, how does one deal with security in "isomorphic JavaScript"? Is it just the rendering running on both sides with all business logic remaining on the server? If so, the main advantage would be that you could combine the responsiveness and speed of a client-side app with the ability to serve static HTML for clients without JavaScript like some search engine bots, right?

sim0n 12y ago
Exactly. The client and server share the bulk of the same code so the server is able to generate the initial response to a request and then the client can continue where the server left of by binding to DOM events, etc and handling further client-use of the app.
morgante 12y ago
Right, with isomorphic JavaScript your server isn't trusted either. A good paradigm for this is to have a completely separate API server, which is secure, while the "frontend code" (which might run on either the server or client) isn't trusted. Also, the benefit of isomorphic JavaScript isn't chiefly for SEO (there are other solutions to that problem, such as PhantomJS), it's in being able to have fast initial pageloads even for rich JS apps.
- progx 12y ago
  But isn't it a little fake? e.g. form validation: In the examples i see, the client did not have any validation code, it sends the raw data to the server, which validates and respond to to the client. So the client did not use the same code.
  - morgante 12y ago
    > But isn't it a little fake? What example are you looking at? I think you maybe don't understand how isomorphic apps work... Take form validation: 1) Your "frontend" code (which runs on both/either client & server) does a quick sanity check, purely for responsiveness. 2) Your API server does actual validation of code. Of course, your API server isn't running the same code as the client—you can't have the client talking directly to your database, for example. Rather, the idea is that the "frontend" can be rendered on the server & client.
  - deleted 12y ago
    [deleted]

by phaer 12y ago

sim0n 12y ago

Exactly. The client and server share the bulk of the same code so the server is able to generate the initial response to a request and then the client can continue where the server left of by binding to DOM events, etc and handling further client-use of the app.

morgante 12y ago

Right, with isomorphic JavaScript your server isn't trusted either. A good paradigm for this is to have a completely separate API server, which is secure, while the "frontend code" (which might run on either the server or client) isn't trusted. Also, the benefit of isomorphic JavaScript isn't chiefly for SEO (there are other solutions to that problem, such as PhantomJS), it's in being able to have fast initial pageloads even for rich JS apps.

progx 12y ago
But isn't it a little fake? e.g. form validation: In the examples i see, the client did not have any validation code, it sends the raw data to the server, which validates and respond to to the client. So the client did not use the same code.
- morgante 12y ago
  > But isn't it a little fake? What example are you looking at? I think you maybe don't understand how isomorphic apps work... Take form validation: 1) Your "frontend" code (which runs on both/either client & server) does a quick sanity check, purely for responsiveness. 2) Your API server does actual validation of code. Of course, your API server isn't running the same code as the client—you can't have the client talking directly to your database, for example. Rather, the idea is that the "frontend" can be rendered on the server & client.
- deleted 12y ago
  [deleted]