Live data from Hacker News

Ruby, Let's Take a Break. I Want To Date Node For a While.

grantmuller.com

11–20 of 32 posts

Re: Ruby, Let's Take a Break. I Want To Date Node For a While.

#11
post #6
post #4

Earlier quoted context omitted.

I keep hearing about this, but has anyone actually done this?

And furthermore, what are the security ramifications of doing this? At first glance, it seems attackers would be able to forge JSON objects resulting in "mass-assignment" style vulnerabilities (unless there is lots of protection logic) when sending JSON objects back to the server side. However, going in the other direction (sending JSON from server to client) is a very common pattern.

This. Most tutorials of Backbone/Ember js apps I've seen have thin backends that commit any json objects the clients send them.

Data sanitization and validation on the backend should be as thourough as that of the client, if not more.

Re: Ruby, Let's Take a Break. I Want To Date Node For a While.

#12
post #6
post #4

Earlier quoted context omitted.

I keep hearing about this, but has anyone actually done this?

And furthermore, what are the security ramifications of doing this? At first glance, it seems attackers would be able to forge JSON objects resulting in "mass-assignment" style vulnerabilities (unless there is lots of protection logic) when sending JSON objects back to the server side. However, going in the other direction (sending JSON from server to client) is a very common pattern.

You can just sign the data, then they can't just change it.

Re: Ruby, Let's Take a Break. I Want To Date Node For a While.

#13
post #6

Earlier quoted context omitted.

And furthermore, what are the security ramifications of doing this? At first glance, it seems attackers would be able to forge JSON objects resulting in "mass-assignment" style vulnerabilities (unless there is lots of protection logic) when sending JSON objects back to the server side. However, going in the other direction (sending JSON from server to client) is a very common pattern.

This. Most tutorials of Backbone/Ember js apps I've seen have thin backends that commit any json objects the clients send them. Data sanitization and validation on the backend should be as thourough as that of the client, if not more.

Who in their right mind does data validation on the client? However, there are (very easy) ways to store data on the client and be sure they haven't been tampered with. Just HMAC it along with a secret and check it next time.

Re: Ruby, Let's Take a Break. I Want To Date Node For a While.

#14
I don't know, I want to make an HTTP spider and I don't want to have one process per request, so the obvious thing was to use something asynchronous. Still, Python+gevent sounds better than node, so I don't see the advantages of using Javascript for that.

What does it get me over Python+gevent, which has a more natural asynchronous programming syntax?

Re: Ruby, Let's Take a Break. I Want To Date Node For a While.

#15
post #8
post #2

A friend who is wrapping up the last year of his computer science education asked me last night "so what's this node.js stuff all about?". I thought about it for a few seconds and then told him the value of writing a web-app in node was the ability to use 1 language from top to bottom. In my experience, most of the detractors of node seem to miss the value that a homogenous programming environment can bring. I'm inte…

I've used node, and I just don't see it. You can share fragments of code, but for reasons of both security and logic not much more. In my view, the evented nature of node negates most of the pluses of one language. Additionally, javascript is a shitty language if what you want is a large amount of business logic. Python and ruby are much more concise and expressive. This is a huge win that a lot of people overlook. N…

Er... you want expressiveness, so you ditch JavaScript and use Java?

Re: Ruby, Let's Take a Break. I Want To Date Node For a While.

#16
The strange thing about this is that I've found that both make great additions to my toolbox, and when making my language choice I don't pick JS or Ruby so much as I pick Node or Rails/Sinatra and I don't do the same things with each stack.

I've long gotten past worrying too much about languages Ruby and JS are so close to each other that switching between the two is a frictionless process.

Re: Ruby, Let's Take a Break. I Want To Date Node For a While.

#18

I don't know, I want to make an HTTP spider and I don't want to have one process per request, so the obvious thing was to use something asynchronous. Still, Python+gevent sounds better than node, so I don't see the advantages of using Javascript for that. What does it get me over Python+gevent, which has a more natural asynchronous programming syntax?

> I don't want to have one process per request, so the obvious thing was to use something asynchronous

There's these amazing things called threads you can use too

Re: Ruby, Let's Take a Break. I Want To Date Node For a While.

#19

I don't know, I want to make an HTTP spider and I don't want to have one process per request, so the obvious thing was to use something asynchronous. Still, Python+gevent sounds better than node, so I don't see the advantages of using Javascript for that. What does it get me over Python+gevent, which has a more natural asynchronous programming syntax?

[deleted]

Re: Ruby, Let's Take a Break. I Want To Date Node For a While.

#20

Earlier quoted context omitted.

This. Most tutorials of Backbone/Ember js apps I've seen have thin backends that commit any json objects the clients send them. Data sanitization and validation on the backend should be as thourough as that of the client, if not more.

Who in their right mind does data validation on the client? However, there are (very easy) ways to store data on the client and be sure they haven't been tampered with. Just HMAC it along with a secret and check it next time.

My startup uses node to handle all database operations and essentially only serves JSON via AJAX, while the most HTML it sends is basically . The entire app itself along with user-generated content depends on a few large (highly variable) objects sent as JSON where the DOM is manipulated based on this minified data.

As a bit of a backup measure (mainly to prevent XSS), the client-side javascript sanitizes (which is what I believe you partly mean by data validation) all objects sent to the client when as they receive it. So anyone using the intended client-side script should never be susceptible to XSS.

But if by "data validation" you were referring to concepts like whether or not a user has permission to access/modify some part of the database, of course that is checked server-side.

Post reply on HN