Allow middleware for oob endpoints

[joscha]

Is there a possibility to prevent certain reads/writes to certain endpoints based on the request? E.g. how would one intercept a call to mortimer.router(Book).bind(app); ?

[topliceanu]

Yes!

You can use the middleware mortimer provides like so:

// OR Use mortimer's middleware functions just for data fetching.
app.get('/api/book/:bookId', [someFancyMiddleware], mortimer.middleware(Book, 'read'));

There are a total a 7 allowed actions implemented: read, create, update, delete, readAll, updateAll, deleteAll This way you can choose which REST actions to support and you can write your own middleware for stuff like autorization or data sanitation etc. and put it in front of mortimer's middleware

[joscha]

OK, I read that in the docs - was just hoping the simple OOB routing that provides the version, etc. would allow that as well.

[topliceanu]

I feel that's less flexible. What if you want to add many middleware functions? What if you need different middleware for different verbs on the same resource. Putting all that into configs seems clumsy.

I'll keep the one-liner version which is useful for bootstrapping projects, but the library is going in the direction of a collection of middleware to help you build REST apis over mongoose with express.

What do you think?

On Fri, Dec 7, 2012 at 10:30 PM, Joscha Feth notifications@github.comwrote:

OK, I read that in the docs - was just hoping the simple OOB routing that provides the version, etc. would allow that as well.

— Reply to this email directly or view it on GitHubhttps://github.com/topliceanu/mortimer/issues/4#issuecomment-11145139.

Alexandru Topliceanu

[joscha]

I agree with you on the flexibility, but sometimes you might want to add the current user to an entity or restrict access to an entity based on the current user - that currently would involve fetching the user twice, once in the middleware and once in the actual code that manages the entity. It would be nice if one call could be saved. Also I currently see no way to change the behaviour of mortimer REST methods based on the current authenticated user.

[topliceanu]

I'm facing the exact same problem now. I have no idea how to do that in a flexible way.

[joscha]

One possibility would be to allow overwriting the methods that do the magic (e.g. insert, delete, etc.) - that's the approach express-resource took. In theory that should allow for custom-length intercepting through infinite nesting. You could pass the original method as an argument to a custom overwrite, so people could only intercept if they wanted authentication on a resource.

On Wed, Dec 12, 2012 at 3:39 AM, Alexandru Topliceanu < notifications@github.com> wrote:

I'm facing the exact same problem now. I have no idea how to do that in a flexible way.

— Reply to this email directly or view it on GitHubhttps://github.com/topliceanu/mortimer/issues/4#issuecomment-11262335.

[topliceanu]

I have another idea: What if mongoose exposes a middleware that composes a Mongoose.Query object and exposes it in the request.mongooseQuery (or similar) namespace. This way, one can add specific conditions before the query is exec'ed, can add other middleware before/after, and can easily choose the output format for the query. Here'e an example:

app.get '/books', (mortimer 'book'), (req, res) ->
    req.mongooseQuery.exec (errors, books) ->
        if errors? then return res.send 500
        res.send 200 books.forEach (book) -> book.toJSON()

What do you think? Do you see any problems?

[topliceanu]

CC @joscha

[topliceanu]

Hi @joscha,

I've launched a new version of mortimer! It should now address your concerns about extendibility! It's extracted from a production environment I've been running continuously for the past two years. It now has code coverage, generated documentation, running examples, and more.. Please, please let me know what you think!

Thank you!