Sending/receiving pictures/data for exact two users not working, works for other users fine

[gituser789]

Description:

Two users out of 20 can not see images / data send from them to others or received from others.
For all other users, it works fine.

Steps to reproduce:

Send image or datafile from clipboard to chat. But it seems, that this is not reproducable in a standard installation. May there is something broken in our database.

Expected behavior:

Show the real screenshot, not a "retry" picture.
Or show the real datafile, which can be downloaded.

Actual behavior:

Send a screenshot from clipboard always shows this in the chat.

When trying to download this screenshot-file by the download button, the following message appears:
Der Zugriff auf chat.xxxxxxxxxxxxxxxxxxxx.de wurde verweigert Sie sind nicht zum Aufrufen dieser Seite autorisiert.
HTTP ERROR 403

This happens only for the two users, but in all chats (can not open send and received pictures / files)
All other users see the pictures / files.

Server Setup Information:

• Version of Rocket.Chat Server: 3.16.2
• Apps Engine Version: 1.27.1
• Operating System: Debian GNU/Linux 10 (buster) Linux 4.19.0-17-amd64 Refactored and reorganised entire css/less files and logic. #1 SMP Debian 4.19.194-2 (2021-06-21) x86_64 GNU/Linux
• Deployment Method: tar
• Number of Running Instances: 1
• DB Replicaset Oplog:
• NodeJS Version: v12.18.4
• MongoDB Version: 4.2.14 / wiredTiger (oplog Enabled)

Client Setup Information

• Desktop App or Browser Version: Browser Version: Chromium Version 91.0.4472.114 (Offizieller Build) Arch Linux (64-Bit)
• Operating System: Manjaro Linux

Additional context

We are using LDAP, but this seems to work, because the 2 users can log into their account and work with the chat.
File upload from all users (also this 2) is working, because others can download their send files.
But this 2 users can not open their own send files/pictures and received files/pictures from others.
Seems to be a problem with access to the database.

the two users are "verified" users.

This option is set per default to True
Protect Uploaded Files = True (Only authenticated users will have access)

When setting this option to False, data handling works for all users

Any hints there what to check next?

Relevant logs:

No relevant logs found on server.

[johncrisp]

Hi and thanks for reporting this.

But it seems, that this is not reproducible in a standard installation.

This would intimate that there is not an issue with Rocket.Chat but with your own install which is a support issue.

No relevant logs found on server.

So it doesn't look like much is wrong with Rocket.Chat itself?

Der Zugriff auf chat.xxxxxxxxxxxxxxxxxxxx.de wurde verweigert Sie sind nicht zum Aufrufen dieser Seite autorisiert.
HTTP ERROR 403

First, what sort of file storage are you using? GridFS or something else?

Also you make no mention of a webserver/proxy - there will be something logging your 403 error.

There doesn't appear to be any evidence of a bug in Rocket.Chat at this point.

I would suggest you move this conversation to either https://forums.rocket.chat/ or https://open.rocket.chat/channel/support and we can try and help you there. Note that if you have a support contract then please contact support directly.

[alexharrington]

We had this. Turned out to be that some users were connecting to RocketChat using an old hostname which still points to the server, but isn't the primary one we use anymore.

So the client was connecting to chat.olddomain.com but the images were being served from chat.newdomain.com

[gituser789]

@alexharrington thats it!
We hat chat.shortform.com, which is pointing on chat.longformdomain.com
So this two users were using the chat.shrotform.com, all others the long form.

But we are wondering why it was working for more than one year.
And why is the same forwarding working for the whole chat, but not for files/graphics?

Is it possible to detect such 'miss connection' within rocket.chat software?

[gituser789]

works for us.
Should I close this issue, or should it remain open due to some improvements in rocket.chat are possible?

[alexharrington]

@gituser789 I'm not involved in the project - just a user. I have no say in whether or not a change is necessary or indeed why this has become an issue now!