
Meteor allow/deny vulnerability disclosure - dvt
https://forums.meteor.com/t/meteor-allow-deny-vulnerability-disclosure/39500
======
btown
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
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
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

~~~
sergiotapia
If you use contexts (which is a fancy way of saying use a business layer) for
your applications logic, you end up with small, isolated functions that are
super easy to test.

`mix test` just nukes your tests and runs them really fast. About 200 tests
run in about 5 seconds. Since tests run so fast you end up writing more tests,
you end up writing smaller functions, you end up with cleaner code. Everything
just falls in the right places almost by itself.

~~~
malloryerik
Do any of you guys use Elixir/Phoenix with React and Absinthe GraphQL?

And how about Clojure(Script)? Now that ClojureScript can consume almost all
JS libraries, isn't it a serious contender?

------
albertgoeswoof
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
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
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.

------
clishem
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
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)

