Closed timolson closed 10 years ago
See this http://stackoverflow.com/questions/518000/is-javascript-a-pass-by-reference-or-pass-by-value-language/5314911#5314911 for an explanation.
One solution is to decrypt the members of the doc argument but if your entire doc is encrypted that won't be possible.
Another solution in collection-hooks is to add doc to the context of the after functions that way you can use this.doc to replace the doc inside after functions.
I'll make a PR for that change and we'll see what @matb33 have to say
@timolson can you test my PR and see if you can get the wanted result.
Just clone my PR repo to your packages folder, make sure your on afterHooks branch and restart the meteor app and it should use the local package for collection-hooks
use this.doc to replace in findOne and this.cursor to replace in find
I understand pass-by-value/ref and am modifying the members of the doc (unsuccessfully), which is surprising. I will test your PR and also try to come up with a simple test case outside our system.
My testcase isn't triggering the server-side hook at all from the client, so maybe I am not using the package correctly. The docs don't say much about this. You can see the test case here:
In your test case you define the after.findOne hook only server-side.
findOne when run on client only run on client i.e. tries to fetch data from minimongo and don't use a method call, like insert, update or remove does with a stub running on client to try and be optimistic about the changes.
If you were to define the after.findOne hook on both client and server the hook would run on client side too when using findOne from client but that would result in decryption being done on client-side.
When findOne is called from server everything works as expected but because autopublish isn't using findOne when publishing the data to client, the data that the client receives isn't changed.
In you case i would actually define the hook server-side on both find and findOne making sure all server side code accessing the data is getting the decrypted data and also all data getting sent to client via publish functions is decrypted that way and when accessing the data on the client it's already decrypted.
Don't think that will actually work, I would probably just decrypt the data in a publish function and "add" the decrypted data with this.added function within the publish function
If you define the find/findOne hook on server only to decrypt the doc's members, when you publish the docs the decrypted docs should be sent to the client and this issue should be resolved without the need to use #64, as you were only decrypting the members and not the whole doc.
We refactored our code to not require this functionality, so I can't justify pursuing this unfortunately. It probably works as advertised, and there was a different problem in our code. I'll close this as bogus.
I'm using an after.findOne() hook to modify (decrypt) a document on the server. The server hook correctly decrypts the database data and modifies the document that was passed into the hook. The client, however, only sees the unmodified (encrypted) document. Is this a limitation of collection-hooks or is there something I'm missing? I thought that modifying the document in the server-side hook would propagate to the client.