Unable to open attachment images in full size or download them

[rmaksimov]

Description:

Since the recent version of RC client 4.40 (iOS) attachment images are not shown in full size and cannot be downloaded

Environment Information:

• Rocket.Chat Server Version: 6.3.3
• Rocket.Chat App Version: 4.40

Steps to reproduce:

1. Post an attachment image to a room
2. Click on it to open in full size
3. Nothing will happen

Actual behavior:

Additional context:

Due to logs on the server it looks as if the RC client tries to request an attachment twice, but only processes the second response and fails

[rmaksimov]

is there any news on this issue? @diegolmello

[dnlsilva]

is there any news on this issue? @diegolmello

Testing on two different servers, it's working normally here, basically I couldn't reproduce it. Considering this we would need more information. Another test you could do is send the same image using the open server and check if the same problem occurs.

[diegolmello]

@rmaksimov Can you reproduce on https://open.rocket.chat?

[rmaksimov]

Thanks for the quick reply

I'm using nginx as a reverse proxy and client certificates for authentication

There are two entries in the nginx log file for each image requested from a mobile client:

192.168.0.2 - - [29/Sep/2023:13:27:06 +0300] "GET /file-upload/VfU8K6WdVn4rrM73j/Clipboard%2520-%2520August%252031,%25202021%25209:36%2520PM?rc_uid=45gwoUyl2cjsSyW3n&rc_token=MYjHv333eVv53HZGVCD_rYbJSkosgR_Lwi24HZmuB5X HTTP/1.1" 400 246 "-" "Rocket.Chat/47248 CFNetwork/1410.0.3 Darwin/22.6.0" "-"
192.168.0.2 - - [29/Sep/2023:13:27:06 +0300] "GET /file-upload/VfU8K6WdVn4rrM73j/Clipboard%252520-%252520August%25252031,%2525202021%2525209:36%252520PM?rc_uid=45gwoUyl2cjsSyW3n&rc_token=MYjHv333eVv53HZGVCD_rYbJSkosgR_Lwi24HZmuB5X HTTP/1.1" 200 190022 "-" "Rocket.Chat/4.40.0 (iPhone; iOS 16.7; Scale/3.00)" "-"

As you can see, the first one has strange UA and looks as if there is no client certificate provided, resulting in a status code of 400 The mobile client receives the first response and ignores the second one (as expected)

Also note, that the second request has double encoding for special characters

[rmaksimov]

@diegolmello, @GleidsonDaniel

The issue is still present I'm on the latest version of RC for iOS (4.42.2.51088) as well as using the latest version of RC on the server side (6.4.6) Here are some more nginx debug log entries:

2023/11/16 01:14:52 [debug] 2830#0: *103940 http header: "User-Agent: Rocket.Chat/51088 CFNetwork/1410.0.3 Darwin/22.6.0"
2023/11/16 01:14:52 [debug] 2830#0: *103940 http header done
2023/11/16 01:14:52 [info] 2830#0: *103940 client sent no required SSL certificate while reading client request headers, client: <REDACTED: IP>, server: <REDACTED: SERVER>, request: "GET /file-upload/859342b4dab243adf4638152/Clipboard%20-%20November%2016,%202023%201:14%20AM.png?rc_token=KXa1h6kX005gHGZzSA1oUvANojXxLpawBG56-wMjA_J&rc_uid=1sQ2pajX9hC5xJwX9 HTTP/1.1", host: "<REDACTED: SERVER>"
2023/11/16 01:14:52 [debug] 2830#0: *103940 http finalize request: 496, "/file-upload/859342b4dab243adf4638152/Clipboard - November 16, 2023 1:14 AM.png?rc_token=KXa1h6kX005gHGZzSA1oUvANojXxLpawBG56-wMjA_J&rc_uid=1sQ2pajX9hC5xJwX9" a:1, c:1
2023/11/16 01:14:52 [debug] 2830#0: *103940 event timer del: 23: 522146499
2023/11/16 01:14:52 [debug] 2830#0: *103940 http special response: 496, "/file-upload/859342b4dab243adf4638152/Clipboard - November 16, 2023 1:14 AM.png?rc_token=KXa1h6kX005gHGZzSA1oUvANojXxLpawBG56-wMjA_J&rc_uid=1sQ2pajX9hC5xJwX9"
2023/11/16 01:14:52 [debug] 2830#0: *103940 http set discard body
2023/11/16 01:14:52 [debug] 2830#0: *103940 charset: "" > "utf-8"
2023/11/16 01:14:52 [debug] 2830#0: *103940 HTTP/1.1 400 Bad Request

[Baizkunthaz]

Hey @rmaksimov , I am very willing and interested in contributing to the org, but as I am new to open source, could you please guide me on how to start?

[GopalVerma1303]

Hey @Baizkunthaz! Are you still working on this issue?

[rmaksimov]

@diegolmello, @GleidsonDaniel is there any plan to fix this issue? one hundred percent that this is related to mTLS and only affects mobile RC

Disabling mTLS on nginx as follows

ssl_verify_client off;

solves the problem, but it's not the appropriate way to solve it

[diegolmello]

@rmaksimov We have plans to fix it, but not enough hands, so it can't be prioritized right now. If you post enough information to reproduce it, perhaps someone from the community can work on it. Even better if you can contribute yourself.

[rmaksimov]

Prior to 4.40 everything was fine with mTLS on mobile RC, so some recent changes should be reviewed

To enable mTLS on the server side:

1. Add the following lines to the corresponding configuration file of nginx

   ssl_verify_client on;
   ssl_client_certificate /etc/nginx/certs/ca.crt;

2. Generate CA and client certificates
3. Reread nginx configuration file with

   nginx -s reload

While connecting to a server using mobile RC specify the client certificate using the "Apply your certificate" button

[rmaksimov]

It looks like there is a regression with the described issue in the latest version of RC (iOS) It was working fine with some numbers (two?) of previous releases

[diegolmello]

Need more info.

[rmaksimov]

The behaviour is almost the same as described above: attachment images are not displayed in either preview mode or full size And nginx's logs show that an RC client does not send a client TLS certificate while trying to download an attachment

client sent no required SSL certificate while reading client request headers

[rmaksimov]

@diegolmello I have found a weird way that is allowed to force attachments to load on iOS - it is necessary to put any emoji on the message containing it Moreover it does not matter from which RC client this action is performed (tested in conjunction with RC desktop client)

[rmaksimov]

Well, on iOS attachments are loading and displayed only when some action is taken on a message containing them The actions are as follows:

• put emoji
• start / unstar
• pin / unpin