Upsert from client with allow/deny rules

[Tarang]

Maybe one way to let it play well with allow and deny rules is another upsert rule?

It might be better than going through both update and insert validation checks.

[matteodem]

I don't know the current implementation, but shouldn't it only go into one of the validation checks, depending on if the document already exists or not?

If it is like that a seperate "upsert" check shouldn't be necessary

[Tarang]

At the moment it just denies it outright on the client.

I'd imagine if it let it through it would have to check. The issue is the client wont always be aware of all the documents and could cause problems if it tries to insert a document that already exists. So I'd imagine both have to be checked (insert and update)

It might be better to have a separate upsert rule since the allow/deny checks can be checked client side and it can be validated server side correctly too. Or have both (update and insert) checked?

[glasser]

The idea behind allow/deny is that it makes it easy to get start writing your Meteor app when you haven't fully worked out your data model, and where it's easier to just put insert/update/remove directly into event handlers (or at the console!) instead of defining methods.

But defining methods isn't that hard! In my opinion, defining a one-line method that calls upsert is a whole lot easier than writing a correct and secure validator for an arbitrary external upsert.

We'd like to keep the "beginner's API" of allow/deny simple (it already doesn't support arbitrary selectors for update and remove) instead of adding more features to it which probably will be harder to use than writing a one-line method.

[waiholiu]

Hi @glasser , in light of this issue, just to confirm, upsert is denied outright on the client?

Should the documentation http://docs.meteor.com/#/full/upsert be changed to say that upsert doesn't work "anywhere" but only on the server?

[glasser]

No, upsert works on both the client and the server. But it doesn't work on allow/deny-restricted update RPC methods.

So when can you use it on the client? You can use it within stubs on the client, and you can also use it from the client in insecure mode.

[llvasconcellos]

@glasser So GOD DAMN document it!!!
Meteor documentation is frustrating. No examples. Lacks a lot of information. It makes me waste a HUGE amount of time in stupid things.

[merlinstardust]

@llvasconcellos please there is no need to curse. A simple polite request will go a long way.

Alternatively, if you find that things are not documented well, you can always make a PR to contribute to and improve the docs yourself. https://github.com/meteor/docs

[kakadais]

@llvasconcellos I believe that you can always run away from this meteor world or othes as well bro.

[kakadais]

@glasser I'm wondering that the idea of CRUD in client is just for making it easy for newbie? I thought that could be a new approach and one of the good idea to build an application if we could care the security things more. I just want to know we have to stop to use it on the security perspective.

[llvasconcellos]

@kakadais I did it! And I'm glad I did. Also, still mad with the time wasted on this piece of software.

[kakadais]

@llvasconcellos Congrats for you- but I want to carefully warn you that there's no best or worst tech in the world, but only appropriate tech with smart enough person to know where and how to use ;)

[llvasconcellos]

@kakadais I disagree. Some people are smart enough to understand that some techs aren't worth the effort.

[kakadais]

@llvasconcellos KKK Yeah but first of all, we don't call the people 'smart' who said that 'smart' to himself bro ;) Nice to have a conversation- bye-