No control over order of remotes().before hook

[bitmage]

I have two hooks attached to remotes().before, like so:

app.remotes().before('*.*', test1)
app.remotes().before('Company.someAction', test2)

Regardless of which order I put them in, test2 always runs before test1. What is the intended order of operation of these hooks? Should I be able to control it by changing the order I define them in?

[bitmage]

I did some more testing. The order is predictable as long as I have multiple hooks with the *.* pattern. As soon as I introduce a more specific pattern though, it runs before any of the general hooks.

To work around this, I've implemented a custom 'before' hook that intercepts everything with *.* and lets me do my own matching.

const _ = require('lodash')
const matchOrStar = ([p, s]) => p === '*' || p === s
const match = (pattern, string) => {
  if (!~string.indexOf('.')) return false
  const matchup = _.zip(
    pattern.split('.'),
    string.split('.')
  )
  return _.every(matchup, matchOrStar)
}

// Define a custom before hook because loopback changes the ordering based on the specificity of the pattern.
// We don't want that!
const before = (pattern, cb) => {
  app.remotes().before('*.*', (ctx, next) => {
    match(pattern, ctx.methodString) ? cb(ctx, next) : next()
  })
}

before('*.*', lookupAccountId)
before('Company.analysis', cacheStuff)

This works, but it's pretty disapointing that I have to jump through these hoops.

[bajtos]

The order is predictable as long as I have multiple hooks with the . pattern. As soon as I introduce a more specific pattern though, it runs before any of the general hooks.

I believe this is by design: we run more specific patterns first, before running general patterns like *.*. See strong-remoting's lib/remote-objects.js

@raymondfeng @ritch could you please confirm?

If you want to setup a "before" hook that's always executed before any other "beforeRemote" hooks, then you should use a custom strong-remoting phase as explained here: https://loopback.io/doc/en/lb3/Using-current-context.html#use-a-custom-strong-remoting-phase

[stale]

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

[stale]

This issue has been closed due to continued inactivity. Thank you for your understanding. If you believe this to be in error, please contact one of the code owners, listed in the CODEOWNERS file at the top-level of this repository.