Meteor.methods.addMiddleware and Meteor.methods.myMethod.addMiddleware about meteor

[jonathanKingston]

Speaking with Mike on IRC, I suggested this instead: https://gist.github.com/2552266

[mikebannister]

At first I got this working in the meteor dev branch but then it was easy to see how to extract it.

Demo

Code

Definitely took some inspiration from @jonathanKingston's gist, thanks!

[possibilities]

Code lives here now if anyone is interested (; It's evolved quite a bit, using it happily in a couple projects.

https://github.com/possibilities/meteor-filters

[jonathanKingston]

The problem as I see it with these solutions currently, they can't reliably be used for security purposes actually.

When a client or another server for that matter calls a meteor method it has the possibility of being undefined as the server starts up. This isn't a problem as the client can keep retrying, however if the filter code has not loaded then that is where a problem springs. I might be checking that they are the emperor of a small island in Thailand or that they have a valid rail card number in a filter method. If this filter method is undefined and the other method is defined, it seems as though the method would run.

Ok this is a slim chance of firing in the current set-ups, but Meteor could be come a far more scalable solution where it gets rolled onto hundreds of instances all being pulled up and down and the moment that happens a client could be trying to invoke a method.

This sort of problem doesn't happen with Rails as it is fully evaluated before being executed. Now this issue could be solved in several ways:

• Meteor has a lib directory we can use which we could make project makers put code in they need to load, at the moment this gets called first so that would be an optimal place to put the code but what would be great is if we could change this to be invoked and complete before Meteor.startup.
• We could the change Meteor methods api to make all start-ups be part of that object call, still not ideal as you can access the Meteor.methods calls where you like

[possibilities]

Sorry but I don't think that really adds up, the server code is all loaded before clients are served

http://hastebin.com/ritatosato.lua

[jonathanKingston]

@possibilities Yeah sorry I was mixing my head with collections which the server side sometimes calls.
I will do some more testing on this code :).

[jonathanKingston]

Just logging what we spoke about @possibilities.
I think the return value of the filter should be an array of the arguments going into the next filter/method.

so a one argument return would be: return ['value'];

To cancel the chain of filters and not fire the method that they are wrapping you would return false; an exception would do the same functionality too.

[possibilities]

For anyone that cares about this... (; I'm now using this in a couple important places so I've vastly improved the implementation. The README has most of the details but in a nutshell it's more flexible, less buggy and the code is far prettier.

https://github.com/possibilities/meteor-filters

@jonathanKingston ...

I think you might be happier with it now. You can return a single value in or out of an array and it's treated the same way.

I still can't get down with passing false as a way to stop the filter chain from completing... I think since we're talking about Meteor.methods throwing a Meteor.Error is the right way to end the chain and communicate back to the client that the chain didn't complete.

The other reason I don't like it is what if I want to wrap a meteor method that takes a single boolean value as an argument? I could special case it but it wouldn't play nice with the next() approach explained here https://github.com/possibilities/meteor-filters#writing-filters-client-or-server

Last reason I'm not a fan is that you say returning false stops the chain and the original method never fires. Then what? The client doesn't know what happened and if it has a callback it never gets called.

[jonathanKingston]

The reason I wanted the array return was to that a single false wouldn't be considered the same at all, as a boolean output would be: return [false]; or return [true];

The false could then fire a generic Meteor.error.

Personally I just find exceptions as a hack and that if a function is going to be firing an exception it should also return false (Even if it doesn't get fired)... I just like the idea that if for example the exception didn't fire or got caught this function gets stopped and other methods don't fire (defence in depth - however paranoid / ill advised / pedantic it seems I just prefer it).

I also like clear cut api's to functions, the function either returns an array, fires an exception or returns false. Only an array is success.

[jonathanKingston]

Also are you relying on a function always returning the same result (From first glance your code seems to be). So one of your filter calls a collection and updates the times modified for example, does your chain call this several times (or could call it several times depending on the use of next and so on?).

If this is so, I suggest I replicate this functionality in my own filter method as I think we are after different things (as I said before).

[possibilities]

Ah, OK, got ya, definitely thinking differently about this. But to clarify my approach... I don't think of the Meteor methods as event callbacks so the returning false to end the filter chain doesn't resonate with me. And I think explicitly throwing Meteor.Errors to communicate back to the client elegant. Keep in mind Meteor.Errors arrive on the client as a blob of JSON so they can carry a payload with as much or as little specific information about what prevented the Meteor.method from completing... <- very nice methinks. Peace!

[debergalis]

Since this discussion predates the auth implementation, I'm going to close this.

I'm not sure if middleware around methods is the right pattern. Let's use meteor-core for a free-form middleware discussion, or of course a PR if anyone has a concrete idea to propose.

[uxdiogenes]

Even with auth, isn't middleware for methods nice when you need to use them instead of allow/deny rules?