Hi,
is it possible to change the domain name e.g. from rocket.example.org to chat.example.org, just by changing the Website-URL in the admin interface and changing nginx proxy config? Or is the domain name “wired” deeper in the database?
Cheers
m.
Changing site url in settings->general should be the only place you need to update.
Though i’d keep a redirect around as some links like if sharing direct link to a message will break cause I don’t think those references are updated
I upgraded my deployment to enable TLS via reverse proxy. Hence, I changed the site URL from “http://rocket.example.org:3000” to “https://rocket.example.org”.
After that, the URL of previously uploaded files are broken, as the domain in the URL is not updated.
-
the wrong URL is:
https://rocket.example.org:3000/ufs/GridFS:Uploads/663adc9ccb4c4cbebcba68d8/git-branches.png
Theschemeis updated tohttps, but the domain is still the old one.the scheme update is automatically performed by browser. You can see it from chrome’s devtools console:
Mixed Content: The page at 'https://rocket.example.org/direct/c4ryyZRgo3ahz4H5RdiZHwDaG79hzRzswu/uploaded-files-list' was loaded over HTTPS, but requested an insecure element 'http://rocket.example.org:3030/ufs/GridFS:Uploads/663adc9ccb4c4cbebcba68d8/git-branches.png'. This request was automatically upgraded to HTTPS, For more information see https://blog.chromium.org/2019/10/no-more-mixed-messages-about-https.html. -
the expected URL should be:
https://rocket.example.org/ufs/GridFS:Uploads/663adc9ccb4c4cbebcba68d8/git-branches.png.
P.S. If I upload files after upgrade. Then files can be accessed normaly.
Here is the deploy information:
2024-05-08 11:10:47 +--------------------------------------------------------+
2024-05-08 11:10:47 | SERVER RUNNING |
2024-05-08 11:10:47 +--------------------------------------------------------+
2024-05-08 11:10:47 | |
2024-05-08 11:10:47 | Rocket.Chat Version: 6.6.2 |
2024-05-08 11:10:47 | NodeJS Version: 14.21.3 - x64 |
2024-05-08 11:10:47 | MongoDB Version: 5.0.24 |
2024-05-08 11:10:47 | MongoDB Engine: wiredTiger |
2024-05-08 11:10:47 | Platform: linux |
2024-05-08 11:10:47 | Process Port: 3000 |
2024-05-08 11:10:47 | Site URL: https://rocket.example.org |
2024-05-08 11:10:47 | ReplicaSet OpLog: Enabled |
2024-05-08 11:10:47 | Commit Hash: 44b682f6bc |
2024-05-08 11:10:47 | Commit Branch: HEAD |
2024-05-08 11:10:47 | |
2024-05-08 11:10:47 +--------------------------------------------------------+
How have you deployed Rocket?
What is your proxy setup?
(you should start a new thread and not jump on a 4 year old one)
@reetp I think the question in this thread is closely related to my problem after searching around, which confirms that the problem still exists for “newest” versions.
I deployed RocketChat with docker compose following the official guideline, and proxy with Traefik.
The related setup are as follows (not related settings are missed out):
-
before, directly visiting the deploy host
http://rocket.example.org:3030:services: rocketchat: image: registry.rocket.chat/rocketchat/rocket.chat:${RELEASE:-latest} # RELEASE=6.6.2 environment: ROOT_URL: http://rocket.example.org:3030 PORT: 3000 ports: - "0.0.0.0:3030:3000" volumes: - rocketchat-uploads:/app/uploads -
after, visting the TLS enabled reverse proxy
https://rocket.example.org:services: rocketchat: image: registry.rocket.chat/rocketchat/rocket.chat:${RELEASE:-latest} # RELEASE=6.6.2 environment: ROOT_URL: https://rocket.example.org PORT: 3000 volumes: - rocketchat-uploads:/app/uploads labels: traefik.enable: "true" traefik.http.routers.rctls.rule: Host(`rocket.example.org`) traefik.http.routers.rctls.tls.domains[0].main: rocket.example.org traefik.http.services.rctls.loadbalancer.server.port: 3000
Note the following carefully:
"See our releases page and available docker images. "
"Keeping the default release aslatest is not recommended. "
As a sysadmin you don’t want Rocket upgrading itself without you knowing - that ways lies a lot of pain. Choose your version and upgrade when you are ready and happy.
Regarding files.
You might want to take a look at how your files are saved. This is on my test server. It is behind an apache reverse proxy with an external domain being reversed to localhost:3000
(I used Studio 3T for a look around)
db.getCollection("rocketchat_uploads").find({})
GridFS - an original file from when I set this up for testing
{
"_id" : "2aAQ4vocsR9nemJ2M",
"name" : "DJI_0024-J.jpg",
"size" : 646271,
"type" : "image/jpeg",
"rid" : "NpatrG7JMmTZTaHiz",
"description" : "Something like this.....",
"store" : "FileSystem:Uploads",
"complete" : true,
"uploading" : false,
"extension" : "jpg",
"progress" : 1,
"userId" : "hYHbjXWQMSRMu2szG",
"_updatedAt" : ISODate("2019-05-07T14:24:25.713+0000"),
"instanceId" : "akAyTkGsPpKfoFQ5a",
"identify" : {
"format" : "jpeg",
"size" : {
"width" : 2668,
"height" : 1499
}
},
"etag" : "Q4iivL3uLsWosio2H",
"path" : "/ufs/FileSystem:Uploads/2aAQ4vocsR9nemJ2M/DJI_0024-J.jpg",
"token" : "6b8B8aAbaB",
"uploadedAt" : ISODate("2019-05-07T14:24:47.166+0000"),
"url" : "/ufs/FileSystem:Uploads/2aAQ4vocsR9nemJ2M/DJI_0024-J.jpg",
"typeGroup" : "image"
}
Standard Local File store
{
"_id" : "2kj4Frs5eSM9T2Tuu",
"name" : "thumb-281114276_2304713406336080_899189099679253569_n.png",
"size" : 88903,
"type" : "image/png",
"rid" : "NpatrG7JMmTZTaHiz",
"userId" : "tpoo9BGzxqTMeKRM7",
"store" : "FileSystem:Uploads",
"_updatedAt" : ISODate("2022-05-26T18:50:11.614+0000"),
"instanceId" : "FpK6nezgCedhzbcrJ",
"identify" : {
"format" : "png",
"size" : {
"width" : 360,
"height" : 360
}
},
"complete" : true,
"etag" : "2TuMHzQEpdfkrMeqv",
"path" : "/ufs/FileSystem:Uploads/2kj4Frs5eSM9T2Tuu/thumb-281114276_2304713406336080_899189099679253569_n.png",
"progress" : 1,
"token" : "0aBa2bf9DB",
"uploadedAt" : ISODate("2022-05-26T18:50:11.626+0000"),
"uploading" : false,
"url" : "https://chat.myserver.com.info/ufs/FileSystem:Uploads/2kj4Frs5eSM9T2Tuu/thumb-281114276_2304713406336080_899189099679253569_n.png"
}
Note that the port is not save in the URL.
Possibly when your root URL was set to “http://rocket.example.org:3030” this is what happened (and one of many reasons not to do this!)
Look in the uploads table and see what ‘url’ your files have.
Yes, actually I have set RELEASE=6.6.2 in .env file. So, I indeed used a fixed version instead of the latest version.
With regard to the file URL, I have also queried MongoDB and found similar results as your second one, where url for old files have prefix http://rocket.example.org:3030 while new ones have prefix https://rocket.example.org.
I think your first upload file data is targeted at local file system, instead of MongoDB’s GridFS. Nevertheless, this does not make a difference. Since I have change my storage backend from GridFS to Minio’s S3 storage, but the
urlalso contains the “scheme + address” part, like the following:url: 'https://rocket.example.org/ufs/AmazonS3:Uploads/46cfiNPdMgxMvHPpN/thumb-variables_in_workflow.png'
Actually, we can observe that the url is constructed by concatenate ROOT_URL that is currently in use and the path of the uploaded file. Hence, url can be generated at runtime, as we know both the constituent parts. In this way, if we change the ROOT_URL, the access URL exposed to client users will also be updated, and thus will not make the file links break.
Besides, if this is not possible for now, can we run a database update to replace the old url prefix to the new one?
OK - that’s good.
OK - makes sense then.
You probably can, but I’d do a test first and make sure it works - you could try adjusting a single file/url via Mongo and see if it works.
If it does you are gong to have to do some serious DB wrangling to search and replace.
Something like this?
eg:
db.media.find({mediaContainer:"ContainerS3"}).forEach(function(e,i) {
e.url=e.url.replace("//a.n.com","//b.n.com");
db.media.save(e);
});