39 ms·

Meteor allow/deny vulnerability disclosure

70 points by dvt 9y ago

albertgoeswoof 9y ago
This disclosure is great to see, got an email and immediately patched my apps annd redeployed with no downtime and minimal exposure. Meteor is an amazing time saver and a superb framework/build process.
- madamelic 9y ago
  What other frameworks have you worked with? I used to be strongly in favor of Meteor as a time-saver but as I got more exposure, I realized how weak and annoying it is to work with. You are largely stuck into Meteor's ecosystem and at their whim, meaning you have to do things "the meteor way". Things like methods and promises ("Futures") are annoying to me because they abstract away so much. Maybe it is just a matter of "growing up", but I think I am going towards more non-framework frameworks like Choo.js in the future. I used to think Meteor was a quick prototyper, but Choo is infinitely quicker.
  - hexsprite 9y ago
    You don't need to use methods if you don't want to. It's pretty easy to integrate either rest via an integrated express server or if you prefer GraphQL you can host your GraphQL in Meteor. As for Futures, that's not necessary as you can now use ES7 await in Meteor seamlessly on both the client and server out of the box.
- CombatChihuahua 9y ago
  Got mine done yesterday. Also removed some other cruft in the process. Quite painless overall.
clishem 9y ago
Using allow/deny has been an anti-pattern for a while now (using methods is preferred). My projects are not affected, but it is nice to see this so quickly.
- glasser 9y ago
  Yup: https://guide.meteor.com/security.html#allow-deny https://guide.meteor.com/security.html#allow-deny I just submitted a PR to the main Meteor docs pointing there: https://github.com/meteor/docs/pull/164 https://github.com/meteor/docs/pull/164
- CombatChihuahua 9y ago
  You still need to deny all/allow none in order to protect the method pattern.
btown 9y ago
A very common pattern that's been found vulnerable. Glad to see it mentioned here. To the larger point: It's great to see that people are still taking Meteor seriously (there are dozens of us! dozens!). If you're willing to use Mongo - which is VERY flexible if you use it as a materialized view that's fed by other processes, rather than the canonical source of CRUD data - then there's still no better way in 2017 than Meteor/React to prototype a real-time interface whose infrastructure you control. Almost all the code is regular old React, and there's minimal impedance mismatch moving from Meteor HOCs that grab a nested Mongo object, to HOCs that grab a nested object from GraphQL/Apollo allowing you to use other databases.
- sergiotapia 9y ago
  I disagree, Meteor project are quick to ramp up but the second something goes wrong it's just a nightmare. Code is not structured at all, strange packages to do things that fall by to the sides, performance issues that are hard to track/debug. Testing is still a third-class citizen in Meteor for some reason. The official guide mentions testing, but in the four times I've tried to follow it over the course of a year, I could never get it to work properly. On the flipside, using Elixir and Phoenix you know exactly what's going on and why, you have real control over your DB queries. You can benchmark properly. Your tests are 100% real and accurate, and run properly. It's much better. You sleep better at night that's for sure. I say this as someone who has used Meteor for multiple projects and used to love it!
  - thsowers 9y ago
    Agree. I've used Meteor for several large projects and this has been my overall feel. MDG didn't take official stances when it was needed (e.g. Router), and the "Meteor way" to do things was constantly changing. Now there is only one developer left working on Meteor, where the rest of their resources have been dumped into Apollo, and Galaxy their self hosted service. I can't speak to Apollo, but my experience with Galaxy has been frustrating and I eventually moved away from it. For new projects I'm looking into Elixir + Phoenix, Vue, and others. Could you speak to your testing experience in a large app with Phoenix + Elixir? You mentioned that testing has always been a third class citizen in Meteor and I have to agree. Meteor was great to get started with, and like sergiotapia I used to love it. After working with it for a while, I think Meteor's limitations (particularly mongo) really start to show, and it lacks the driving development behind it that new frameworks like Phoenix and Rocket have

70 points by dvt 9y ago

This disclosure is great to see, got an email and immediately patched my apps annd redeployed with no downtime and minimal exposure. Meteor is an amazing time saver and a superb framework/build process.

madamelic 9y ago
What other frameworks have you worked with? I used to be strongly in favor of Meteor as a time-saver but as I got more exposure, I realized how weak and annoying it is to work with. You are largely stuck into Meteor's ecosystem and at their whim, meaning you have to do things "the meteor way". Things like methods and promises ("Futures") are annoying to me because they abstract away so much. Maybe it is just a matter of "growing up", but I think I am going towards more non-framework frameworks like Choo.js in the future. I used to think Meteor was a quick prototyper, but Choo is infinitely quicker.
- hexsprite 9y ago
  You don't need to use methods if you don't want to. It's pretty easy to integrate either rest via an integrated express server or if you prefer GraphQL you can host your GraphQL in Meteor. As for Futures, that's not necessary as you can now use ES7 await in Meteor seamlessly on both the client and server out of the box.
CombatChihuahua 9y ago
Got mine done yesterday. Also removed some other cruft in the process. Quite painless overall.

clishem 9y ago

Using allow/deny has been an anti-pattern for a while now (using methods is preferred). My projects are not affected, but it is nice to see this so quickly.

glasser 9y ago
Yup: https://guide.meteor.com/security.html#allow-deny https://guide.meteor.com/security.html#allow-deny I just submitted a PR to the main Meteor docs pointing there: https://github.com/meteor/docs/pull/164 https://github.com/meteor/docs/pull/164
CombatChihuahua 9y ago
You still need to deny all/allow none in order to protect the method pattern.

btown 9y ago

A very common pattern that's been found vulnerable. Glad to see it mentioned here. To the larger point: It's great to see that people are still taking Meteor seriously (there are dozens of us! dozens!). If you're willing to use Mongo - which is VERY flexible if you use it as a materialized view that's fed by other processes, rather than the canonical source of CRUD data - then there's still no better way in 2017 than Meteor/React to prototype a real-time interface whose infrastructure you control. Almost all the code is regular old React, and there's minimal impedance mismatch moving from Meteor HOCs that grab a nested Mongo object, to HOCs that grab a nested object from GraphQL/Apollo allowing you to use other databases.

sergiotapia 9y ago
I disagree, Meteor project are quick to ramp up but the second something goes wrong it's just a nightmare. Code is not structured at all, strange packages to do things that fall by to the sides, performance issues that are hard to track/debug. Testing is still a third-class citizen in Meteor for some reason. The official guide mentions testing, but in the four times I've tried to follow it over the course of a year, I could never get it to work properly. On the flipside, using Elixir and Phoenix you know exactly what's going on and why, you have real control over your DB queries. You can benchmark properly. Your tests are 100% real and accurate, and run properly. It's much better. You sleep better at night that's for sure. I say this as someone who has used Meteor for multiple projects and used to love it!
- thsowers 9y ago
  Agree. I've used Meteor for several large projects and this has been my overall feel. MDG didn't take official stances when it was needed (e.g. Router), and the "Meteor way" to do things was constantly changing. Now there is only one developer left working on Meteor, where the rest of their resources have been dumped into Apollo, and Galaxy their self hosted service. I can't speak to Apollo, but my experience with Galaxy has been frustrating and I eventually moved away from it. For new projects I'm looking into Elixir + Phoenix, Vue, and others. Could you speak to your testing experience in a large app with Phoenix + Elixir? You mentioned that testing has always been a third class citizen in Meteor and I have to agree. Meteor was great to get started with, and like sergiotapia I used to love it. After working with it for a while, I think Meteor's limitations (particularly mongo) really start to show, and it lacks the driving development behind it that new frameworks like Phoenix and Rocket have