Repository navigation
Disable all remote methods and enable only selected ones (white-list) #651
Description
There is a bunch of existing open/closed issues with questions how to hide the method of the model. My question is about how can all the methods be disabled first and then enabled only those which are necessary? (basically, duplicates this comment: #465 (comment))
Here is the simple function which hides all the methods of the model:
/**
* Hides all the methods besides those in 'methods'.
*
* @param Model model to be updated.
* @param methods array of methods to expose, e.g.: ['find', 'updateAttributes'].
*/
var setMethodsVisibility = function(Model, methods) {
methods = methods || [];
Model.sharedClass.methods().forEach(function(method) {
method.shared = methods.indexOf(method.name) > -1;
});
};However, it doesn't hide two groups:
- remote methods, which have to be hidden like this: Model.disableRemoteMethod(name, isStatic)
- custom methods, like User.login or User.resetPassword (didn't find any way to hide them at all);
Could you please advise what would be the correct way to hide everything (without specific call for each method by its name explicitly) and allow only the methods which are necessary?
Reacted by James Koshigoe, John Clow, Peter Liapin, Andres Rodriguez, Federico Jasson, fenixping, maheshiv, rhernandez-applaudo, Rigo B Castro, Michaël P.O. and 1 more
Activity
crandmck commentedon Oct 21, 2014
@bajtos Can you please clarify which part of this is docs and which is an enhancement request.
bajtos commentedon Oct 23, 2014
AFAIK, this is not possible at the moment. Let's keep this issue open to track your request for that. Note that the implementation will require changes in the strong-remoting module too.
You have to call
User.disableRemoteMethodbefore creating the explorer middleware. I have filled a new GH issue to fix that - see #686.After a closer look, this is a pure enhancement. I am going to remove the "doc" label.
[-]Hide all Model REST API methods and enable only necessary[/-][+]Disable all remote methods and enable only selected ones (white-list)[/+]elhoyos commentedon May 12, 2015
I'm able to hide my remote methods from the explorer when using @voitau's function in 2.17.2.
gholias commentedon Sep 16, 2015
great code @voitau, thanks!
I'm new to loopback, what is the best place to put that code so I can use for all my models?
66 remaining items
ebarault commentedon Dec 1, 2016
@c3s4r thanks for bringing this mixin through
essentially the difference is that the solution proposed in this discussion can automatically enable only the methods explicitly covered by static ACLs in the model configuration, so you don't have to enumerate them manually once more
yes, the idea is to port it as an npm module ultimately
c3s4r commentedon Dec 2, 2016
I just finished creating a module for this. I changed the names of the options a little bit, and added unit tests. I manually tested on loopback 2 and 3, and it seems to be working fine.
https://www.npmjs.com/package/loopback-setup-remote-methods-mixin
I'm also thinking on adding an option for defining new remote methods as well. (Which will be deprecated when the Methods section is implemented for Loopback 3, but can be useful for Loopback 2).
Any comments or suggestions are welcome :)
ebarault commentedon Dec 5, 2016
As I said: I will be pushing the mixin as an npm module soon.
@c3s4r : although you most probably did this with all the best intentions :
prototype.that are enabled from ACLs definitionc3s4r commentedon Dec 5, 2016
@ebarault: Sorry, I did this on my best intentions, didn't want to steal the credit. I couldn't wait because I was needing it for a project, so I putted some effort on doing the unit tests, refactoring the code and publishing the module. Anyways,... let me know how you would like to proceed. I can mention you on the credits, or I can transfer you the project.
ebarault commentedon Dec 5, 2016
-> no pb @c3s4r : not my full credit at all either. We can add a list of contributors from this thread.
It remains that the implementation is broken for now. I'll reach out on your github repo to discuss these, we can co-author it if you will. Just give me a moment to move on with other pending stuff.
c3s4r commentedon Dec 6, 2016
drmikecrowe commentedon Dec 6, 2016
@c3s4r I wouldn't mind being listed as "contributing", but I didn't do the heavy lifting (mainly started the mixin process). @ebarault really took my start and ran with it. NPM username is "drmikecrowe"
c3s4r commentedon Dec 6, 2016
I just pushed the package to npm with the outstanding bug fixed. Also, I added @ebarault and @drmikecrowe as contributors and a credits section in the README file.
https://www.npmjs.com/package/loopback-setup-remote-methods-mixin
ebarault commentedon Dec 6, 2016
hi @c3s4r,
this should be tinkered as it might lead to unexpected results since you make the choice to exclude both instance and static methods for a unique given name, let's continue the discussion on your github.
christiaanwesterbeek commentedon Dec 6, 2016
@ebarault I think it makes sense to create an issue for that at https://github.com/devsu/loopback-setup-remote-methods-mixin/issues
c3s4r commentedon Dec 7, 2016
@ebarault: I'm aware of the limitation, I didn't see it like a big issue, anyways, if you think it should be changed, please open an issue on the other repo and let's continue the conversation there.
go2smartphone commentedon Jun 29, 2017
thanks all for the module, it is cool, but it is slow when you have many models and each of them has many relations. anything we can do about it?
denblackstache commentedon Nov 2, 2017
@go2smartphone Something to deal with
server.on('started', () => { ... })≈5 sec to process each model. Actually it works the same without looking if app is started (Loopback v2.36.0).bajtos commentedon Dec 8, 2017
@go2smartphone @HyperC0der Please open a new issue describing the problem you are facing in detail, ideally with a small app reproducing it (see http://loopback.io/doc/en/contrib/Reporting-issues.html#bug-report).