Secured Push Notifications not loading content on ios

[james-surevine]

Description:

Having installed a trial version of Rocket.Chat enterprise in order to test the 'Secured Push Notifications' feature. It appears this does not work as expected. My android client works well and the notification loads the content (by message ID) as expected. For ios however, the notification content does not load and the notification shows a generic 'You have a new message' message.

Debugging shows that

1. the call from the ios app to /api/v1/push.get?id=... gets a 401. It tries 5 times to load the notification but then gives up and displays the generic message. Further investigation shows that the ios app does not include a x-auth-token header.
2. The call from the android app to /api/v1/push.get?id= does include a x-auth-token header and returns successfully with a HTTP 200 response

Environment Information:

• Rocket.Chat Server Version: 4.7.0
• Rocket.Chat App Version: 4.27.1 (ios app)
• Device Name: Iphone 12
• OS Version: 15.4.1

Steps to reproduce:

1. Installed Rocket.Chat using docker-compose
2. Registered the installation and enabled a trial version of Enterprise Edition
3. Create admin user user1
4. Create user2 on browser client
5. Log in to ios app as user2 and close the app
6. Log in to browser client as user1
7. send a message in the browser client as user1, tagging user 2, e.g. @user2 test1
8. Observe that after a delay a Push notification is received in the ios app, however only a generic 'you have a new message'

Expected behavior:

ios should display a push notification with the content 'test1'

Actual behavior:

ios (After a delay) displays a push notification with generic content of 'you have a new message'

Additional context:

as mentioned above, use tcpdump and analyse to show that the call to load the notification by ID from the ios app did not include a x-auth-token and resulted in a 401 (Unauthorized). This happens 5 times before the app displays the generic notification text.

[diegolmello]

Great job, @james-surevine! The issue might be around here.

Can you work on a fix?

Thanks!

[ankar84]

@james-surevine agree with Diego, great investigation!

With Secure Push feature a have a bit different experience. Most of mobile clients are works perfect, they show message content in Secured Push. But there is some clients (a lot of them actually) that shows generic message. Majority of clients with that issue is definitely iOS clients. But I have users reports about same generic message on Android too! Here is a screen: Here is an iOS screen

There is a temporary workaround - delete app and then install it again. That manipulation fixes Secured Push for some time, but not permanently - it will broke again. And I definitely saw when user first gets generic push message, but then after some time and without re-install of mobile application that same user gets proper message content.

So, my guess is not the only mobile client issue, it could be some server related issue too, or even both. @sampaiodiego agreed with me.

In fact that wonderful feature should be polished to bright like a diamond.

[diegolmello]

@ankar84 I was not aware about that commit on server. Can you keep us updated once it's landed and tested by your team?

[ankar84]

Can you keep us updated once it's landed and tested by your team?

Sure! I will update all that related information when that commit will land to new docker image, guess it will be 4.8.0 soon.

[ankar84]

4.8.1 didn't fix that issue

[thakilla]

Well it does make no sense, but disabling the option "Fetch full message content from the server on receipt" under "Push -> Privacy" fixed all our problems while still getting all of the message content.

[ankar84]

Well it does make no sense, but disabling the option "Fetch full message content from the server on receipt" under "Push -> Privacy" fixed all our problems while still getting all of the message content.

It makes a lot of sense, because now all content of push message go through Apple and Google servers if Fetch full message content from the server on receipt is disabled.

[diegolmello]

@ankar84 @james-surevine I've been trying to reproduce this on Mobile 4.29 (and on the unreleased 4.30) and Server 5.0, but it's working all the time. Going through logs I can see the requests are fetching the message content as expected. Please run your tests and let me know if it's working for you. We can reopen if needed.

[diegolmello]

Nevermind. For some reason, it's started to fail. I'm still investigating.

[ankar84]

As I told you here, majority of the clients works perfect for some time, but then suddenly some of that clients start get dummy push messages. App reinstall fix that problem immediately, bit not permanently.

[wreiske]

This is affecting our instance as well after enabling the enterprise license.

[diegolmello]

We investigated this issue on https://github.com/RocketChat/Rocket.Chat.ReactNative/pull/4487 and we couldn't find anything related to iOS specifically, but we found it on Android. We're aware it does happen on iOS though, so we're rolling out the Android only fix on next update and understand if it could be something on backend side.

[nmagedman]

Thank you, @diegolmello. I appreciate you being on top of this issue! We'd like to re-enable this feature once it's fixed.

[ankar84]

Looks like it could be fixed in https://github.com/RocketChat/Rocket.Chat.ReactNative/pull/4826

[diegolmello]

@ankar84 You're right. I've been testing secured push on the last days and it's working all the time. Let's make the release and you can try it on your side.

[ansiwen]

I have the same problem with the message-id-only notifications, but only for public channels (type "c"), for private channels (type "p") it works as expected. I can see the /api/v1/push.get?id=... requests in both cases and they are all answered with a 200 OK from the RC server, with basically the same JSON data, but in the case of type "c" channels the requests come in many times from the App, until it gives up and just shows the generic notification ("you have a new message"). So it seems like the app ignores or rejects the type "c" notifications and tries to get them again and again.

Edit: ~type "d" (direct messages) also does not work, so it seems the App only accepts background fetches of type "p" channels.~ probably not correct.

[diegolmello]

@ansiwen Do you have E2EE enabled?

[diegolmello]

@ankar84 is this different behavior depending on the room type something that you can reproduce?

[ansiwen]

@ansiwen Do you have E2EE enabled?

@diegolmello No. And I would be surprised if this works for anyone. The model ist simply not up to date: https://github.com/RocketChat/Rocket.Chat.ReactNative/blob/c5e1b9e7fd5fed956e595babacdb9a7658b55867/ios/Shared/Models/RoomType.swift#L11-L14

[diegolmello]

@ansiwen That's not necessarily the issue. It's just to append the username to the push content: User sent a message vs Sent a message.

Also you said direct isn't working as well.

[ansiwen]

Also you said direct isn't working as well.

That's true. I assumed the JSON parsing fails and I have no idea, what else it could be, because the responses from the server look identical besides the type field. I would expect it must be something during this code:

https://github.com/RocketChat/Rocket.Chat.ReactNative/blob/fd210c4713f7101ad91a627d516ee70dda7c9917/ios/NotificationService/NotificationService.swift#L28-L34

[diegolmello]

I see. Please keep investigating and let us know if you find anything odd. I'm happy to work on a fix based on your discovery.

[ankar84]

@ankar84 is this different behavior depending on the room type something that you can reproduce?

We just test case described by @ansiwen here and I can confirm that we see problem with generic push messages from public channels (type "c"). But direct message push in our test was ok. So, guess this is a very good details to het root cause of that problem.

[ankar84]

Here is a recent experiment Android iOS

@diegolmello Conclusion: it's iOS only issue with public channels only

[diegolmello]

Awesome. Thanks, Anton!

[ansiwen]

That all confirms the theory, that the unmarhaling of the JSON data is failing because of the outdated model, and I simply made a mistake with the direct messages.

[diegolmello]

Ok, I'm going to give it a try then.

[diegolmello]

@ansiwen It actually fixed it! We're going to make a release later this week. Thanks for your help!

[diegolmello]

@ankar84 Can you enable secured push on the next release?

[ankar84]

@ankar84 Can you enable secured push on the next release?

I will do it for sure and come back with feedback. Thank you, @diegolmello