6 ms·
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 addi
by peter_l_downs 14y ago
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?
- jonny_eh 14y agoI 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.
- jkrems 14y agoI 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.
- jdavis703 14y agoAvoiding 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.
- nadaviv 14y agoThere'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.
- byroot 14y agoNo. 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.
- nadaviv 14y ago`<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/ 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.
- mikermcneil 14y agoHi 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.
- ZoFreX 14y agoAnd 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_Request_Forgery_%28CSRF%29 https://www.owasp.org/index.php/Top_10_2013-A8-Cross-Site_Re...
- Kiro 14y agoHow 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.
- cvrajeesh 14y agoAccording to HTTP - GET request should be idempotent. Even if you mimic the other verbs using query string, it is still a GET request.
- joshguthrie 14y agoI'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?
- dragonwriter 14y ago> 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.)
- tonyblundell 14y agoIt does look exciting, but I can't trust a framework that promotes saving data on a GET request.
- NikolaTesla 14y agoDefinitely 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.
- tonyblundell 14y agoIf it's on the homepage and in the docs, people will copy it without questioning it. That's why people use frameworks.
- mikermcneil 14y agoNot you though, sounds like!
- tonyblundell 14y agoSarcasm, 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.
- jameycribbs 14y agoI really hope you start using a framework. This would free up more time for you to develop a sense of humor! :)
- tonyblundell 14y agoA sense of humour normally gets you downvotes on here :-p
- spmurrayzzz 14y agoMaintainer 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.
- mikermcneil 14y agoHey 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 http://localhost:1337/user # Find the user with id 1 http://localhost:1337/user/1 http://localhost:1337/user/1 # Create a new user http://localhost:1337/user/create?name=Fisslewick http://localhost:1337/user/create?name=Fisslewick (or send an HTTP POST to http://localhost:1337/user http://localhost:1337/user) # Update the name of the user with id 1 http://localhost:1337/user/update/1?name=Gordo http://localhost:1337/user/update/1?name=Gordo (or send an HTTP PUT to http://localhost:1337/user/1 http://localhost:1337/user/1) # Destroy the user with id 1 http://localhost:1337/user/destroy/1 http://localhost:1337/user/destroy/1 (or send an HTTP DELETE to http://localhost:1337/user/1 http://localhost:1337/user/1)
- smrtinsert 14y agohow would you delete the incorrectly created key from the video? nice work btw, the end to end of it is attractive if somewhat magical.
- peter_l_downs 14y agoI 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.
- firefoxman1 14y agoIf you're looking for a super simple solution, check out Sajak https://github.com/jed/sajak https://github.com/jed/sajak. It's great for making a basic JSON API.