RocketChat
Adding messages doesn't allow timestamp manipulation
I'm writing an application that lets users import their private mesage history into IM rooms, which is a much asked for feature that would significantly ease the pain for many of my users migrating to Rocket.Chat from other systems. To achieve a useful history import, I need to set the timestamp of the imported messages, so that they fit in at the right place of the message history. Just like the built-in importers do (that are only accessible to admins).
I noticed that when I'm using a IModifyCreator to import messages and set a timestamp saving the message to the database throws an error. I can update the message with the correct timestamp later using an IModifyUpdater but then all the imported messages show up as edited, which looks really stupid in my opinion (and is also not true).
The reason for this behavior is that the Rocket.Chat message bridge is using the following method to create new messages
import { sendMessage } from 'app/lib/server/methods/sendMessage';
which is also the method that is used for regular messages sent by users. Because this method was written for live messages it includes a check for time syncing issues which throws the error in my case. The updater, which lets me manipulate the createdAt timestamp, on the other hand uses the update function from the functions directory (instead of the methods directory)
import { updateMessage } from 'app/lib/server/functions/updateMessage';
which is the internal function called by the methods in the methods directory after they performed their checks (and is also used by the built-in importers).
So my question is: Right now Rocket.Chat apps are not able to create messages with an arbitrary creation date. Is this an intentional restriction? If yes, could you explain why you think this is necessary?
If no and this would be considered a bug, fixing this would require to replace the method call in
https://github.com/RocketChat/Rocket.Chat/blob/df238473197d855b7e672b4a074aaa1d59d9d647/app/apps/server/bridges/messages.js#L18
with a call to the matching function in the app/lib/server/functions/sendMessage.js file.
Great work on the apps-engine so far, I'm really excited to see what will be added next! Have a nice day 👋🏻
Hey there, thanks for such a detailed message and issue.
This is actually a tough one because it could easily be abused. It being abused is why we limited it in the first place..however, I completely see your use case and it is valid.
In order to avoid it being abused, do you have any suggestions on how we could do that? Maybe a warning or something to the admin when they install an App which can create messages which don't have their timestamp verified? That probably isn't very viable, so that's why I'm asking for suggestions :)
@heilerich
I think an entitlement management like many other app store like environments have is the best compromise between security and providing an environment for useful plugins.
My preferred solution would be an additional method in the IApp interface, something like getEntitlements, where an app could specify and return any entitlements it needs to run properly. Very similar to the approach the Google Play Store was using in its early days.
Admins could then decide at installation time if they would be willing to grant the app the right to access the requested restricted functions (like message timestamp modification).
At runtime the server then just needs to get the requested entitlements from the App instance and throw an error if the required entitlements for the respective function were not requested on installation.
On a side note: As I hinted above the current system is not actually achieving it's goal of making it impossible to modify timestamps, it just takes slightly more effort to circumvent your restriction. The app I wrote when I opened this Issue is indeed working.
@heilerich interesting idea, I'll make sure @d-gubert sees this and maybe something can happen! I really like this idea and approach, very similar to an idea we had a while ago but we couldn't come up with a good time for it.
It looks like this is related to the Permission System we have on our roadmap. We're still working out the details for the implementation of this, but it is in our radar.
