Hacker News Reader

Comment by peter_l_downs | Hacker News Reader

This looks great! The automatic API generation is a killer feature that makes me want to try this out sometime soon. Only thing that seems strange to me is adding the <resource>/create, <resource>/update, and <resource>/destroy GET endpoints -- why not keep it RESTful?

View on HN

Hey Peter-- RESTful endpoints are supported. The other options are just there for convenience while testing. You can disable those routes later if you like in your routing table. Policy mapping happens at a controller level to solve this very problem and prevent devs from inadvertently granting access to a piece of code they didn't mean to.

# List of all users http://localhost:1337/user

# Find the user with id 1 http://localhost:1337/user/1

# Create a new user http://localhost:1337/user/create?name=Fisslewick (or send an HTTP POST to http://localhost:1337/user)

# Update the name of the user with id 1 http://localhost:1337/user/update/1?name=Gordo (or send an HTTP PUT to http://localhost:1337/user/1)

# Destroy the user with id 1 http://localhost:1337/user/destroy/1 (or send an HTTP DELETE to http://localhost:1337/user/1)

how would you delete the incorrectly created key from the video?

nice work btw, the end to end of it is attractive if somewhat magical.

I saw that the RESTful endpoints also existed, I was just curious about the additional ones. Knowing that I can easily choose to disable them is great to know — maybe mention it in the docs? I think that exposing these routes for testing is a great idea, but depending on them in production would be rather terrible and dangerous.

I can see the desire to be able to execute non-GET commands via the browser's address bar. Another way Sails could accomplish that would be to accept "?method=PUT|POST|DELETE" to mimic the desired HTTP method.

I don't think that solves the underlying problem of side effect-ful/dangerous GET requests that may be easily exploited via CSRF attacks. You really don't want to expose POST/PUT/DELETE actions via GET.

Avoiding GET requests is not a fool proof way to mitigate CSRF. If your website has just one XSS vulnerability an attacker can send POST requests. It's much better to use some kind of token that is always sent with your forms.

There's nothing stopping anyone from sending POST requests to wherever he wants, even without an XSS. the same-domain origin policy only forbids you from reading the response, not from sending the request. CSRF-wise, POST requests are just as vulnerable as GET requests.

Also, if someone does manage to find an XSS vulnerability, using a CSRF token won't be any good - the attacker can simply read the token from your website and use it.

No. Before performing a POST/PUT/DELETE or any other method with side effect to another domain your brother will issue an OPTIONS to get authorization first and will never perform the request if the server do not authorize it.

Then if your authentication is cookie based and you allow to delete resource via GET then all the attacker have to do is to insert <script> or <img> tag on any other domain with the proper src attribute to delete your content silently.

These endpoints are a VERY bad idea and are absolutly not REST. RESTful do not mean CRUD.

`<form>`s are allowed to send POST requests to wherever they want, without any restrictions. By creating a form that points to another domain, and automatically submitting it, you can send a POST request to wherever you want [1].

POST requests can be easily sent cross-domain. NO ONE SHOULD EVER think that just because he's not using GET requests he's safe from CSRF attacks.

[1] See http://jsfiddle.net/8xnB3/5/ for example (which sent this comment).

EDIT: Just to clarify - I'm not saying that exposing those endspoints via GET is a good idea, I think its horrible. But people should be aware that avoiding GET does not protect against CSRF, and you still have to use CSRF tokens.

Hi nadaviv, if you don't want to expose those endpoints via GET, you don't have to. Those are set up that way in development so it's much easier to get started. You have full control over your routing table and access control policies.

And if you have zero XSS vulnerabilities, they may be able to trick users into interacting with a form on a site they control (the "CS" of "CSRF"). CSRF token is definitely necessary.

Reference: https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Re...

How common are CSRF attacks? My sites are not protected at all but I don't know if it's worth the hassle to fix. It just doesn't seem like a big deal and very unlikely to happen.

According to HTTP - GET request should be idempotent. Even if you mimic the other verbs using query string, it is still a GET request.

I'll rephrase something I read this morning on SO about the difference between GET and POST:

"GET request are not supposed to imply any modification on the serveur."

Remember C++ constness?

> I can see the desire to be able to execute non-GET commands via the browser's address bar.

I can certainly see the desire for that as a browser feature; using GET for actions that are neither safe (no impact other than retrieval) nor idempotent is probably not a good way to workaround the lack of such a browser feature, since per the HTTP/1.1 spec, GET should be safe and is defined as idempotent. (See Secs. 9.1.1 and 9.1.2 of RFC 2616.)

Maintainer seems to be aware of the need to keep a conventional RESTful approach. The default state for `routes.js` includes a commented section about setting up HTTP verb routing.

It does look exciting, but I can't trust a framework that promotes saving data on a GET request.

Definitely not promoting it! That's a convenience feature to make it easy to see what's happening during development. You can disable that behavior in your routing table.

If it's on the homepage and in the docs, people will copy it without questioning it. That's why people use frameworks.

Not you though, sounds like!

Sarcasm, nice.

But seriously, I'm new to Node. If I see examples of bad practice on the home page, I've no way of knowing if the framework is going to be teaching me more bad practices in the areas I'm not familiar with yet.

I really hope you start using a framework. This would free up more time for you to develop a sense of humor! :)

A sense of humour normally gets you downvotes on here :-p

Why not?

Because GET requests can be saved as bookmarks, copied and pasted, indexed by search engines, etc.

By the way, I forgot to mention this before, but you can quickly disable this behavior in polices.js or routes.js config file when you're ready to switch to production. In 0.9, you'll be able to generate controllers with this feature disabled from the CLI as well.

If you're looking for a super simple solution, check out Sajak https://github.com/jed/sajak. It's great for making a basic JSON API.

Reply on news.ycombinator.com