-
-
Notifications
You must be signed in to change notification settings - Fork 58
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Better secure access to states and objects DBs in adapter.js #359
Comments
I agree we shouldn't have to rely on using the methods directly. |
We need to stay backward compatible I fear :( So maybe rename "states" and "objects" in adapter for use internally andf only provide the "old used" methods there :-) |
Maybe log a warning on first use of these proxied methods, so we get the devs to update their stuff? |
Would be very important to do this, otherwise there is an easy workaround for the idea of #287 I think at first we should start by providing the methods that are needed and currently have no alternative defined which can be called on the adapter object directly. The most important and maybe only method which pops up in my mind is Checking for adapters which are using |
Checking stuff like this could be done with the TypeScript API which parses the code (JS code too) and generates a structure (tree) from it. That tree can be walked through to identify such constructs. However that is not trivial. |
There also exist some other modules to parse code to an AST object, unfortunately they are including way to less information to indicate where the origin of a function lies. Probably the TypeScript API which you mentioned is the way to go. On the other hand a forum thread asking which methods called on |
Bevause I have a checkout of nearly all repos I could do a grep ;-) |
I think grepping for |
Results: Summary:
Details (if someone wants to do PRs ;-) ) adapter.states
adapter.objects
|
We need to add getObjectList to adapter.js. The rest is already implemented, just needs to be replaced in the adapters. |
Do you find Time to do that in next days ?! Then it could come into 2,.0.0 |
Sure, please check the PR. |
Should we leave this Issue open till then or we need to create a new one |
Step 1: Replace methods which are independent of js-c 2.0
Step 2: Replace methods which are dependent on js-c 2.0 and add js-c 2.0 as adapter dep
Step 3: Remove possibility to directly call adapter.objects and adapter.states in lib/adapter.js |
See ioBroker/ioBroker.js-controller#359 Would make #11 obsolete.
IMHO closed by 4acb1c4 |
We should prevent adapters from calling methods directly on adapter.states and adapter.objects directly. For this we also need to check which methods are not exposed currently (getObjectView e.g.)
The text was updated successfully, but these errors were encountered: