Using a hook.disable() on a service should remove that from the Allow header for REST services

[daffl]

@sjmcdowall commented on Mon Oct 03 2016

I disabled a bunch of service calls using hooks.disable() in a before hook call with code like:

exports.before = {
    all: [],
    find: [],
    get: [],
    create: [hooks.disable()],
    update: [hooks.disable()],
    patch: [hooks.disable()],
    remove: [hooks.disable()]
};

Yet the Allow header still shows all services available:

Allow →GET,POST,PUT,PATCH,DELETE

(From Postman)

I would think that if we use a stock hook.disable() then the associated Allow header component should be removed as well.

[eddyystop]

How would a hook remove the associated Allow header component?

[marshallswain]

This would require collaboration between a hook and response middleware.

[daffl]

Which actually should be possible in the next version because the providers can actually get the hook object (instead of just the result) thanks to feathersjs/feathers#607

[nidkil]

Hi guys, has this functionality been added to update the http allow header if a hook is disabled? Will it also work for the common hook disallow?

[eddyystop]

No, there has been no change.

[nidkil]

Is this a change I could help with?

[eddyystop]

A PR would certainly be considered.

[nidkil]

Okay I will. Do we discuss implementation in this issue or DM?

[eddyystop]

Its best you outline it here so @daffl can comment on it.

[bertho-zero]

Since hooks.disable() can be in conditions etc. I do not think the Allow http header must adapt to this.
The header method must be removed only when it is completely disabled for everyone, as in the example of the first message.

[daffl]

I'm going to close this since it isn't really possible to do this via just hooks anyway because other than the method that is being called, there is no way to figure out which other methods the disable hook is attached to.