Federation invitation from stable29 to main fails

[SystemKeeper]

How to use GitHub

• Please use the 👍 reaction to show that you are affected by the same issue.
• Please don't comment if you have no relevant information to add. It's just extra noise for everyone subscribed to this issue.
• Subscribe to receive notifications on status change and new comments.

---

Steps to reproduce

1. Create a conversation on a stable29-instance
2. Try to invite a user from a main instance

Expected behaviour

Should work

Actual behaviour

User is invited and directly removed again, but the invitation shows up on the main instance (although unable to accept it).

On the stable29 instance:

Error while sending notification to federation server: Client error: POST https://main-instance/ocm/notifications resulted in a `400 Bad request`

When trying again to invite the same user:

{
  "reqId": "UVfKPjzyNAPpzdU0UuHn",
  "level": 2,
  "time": "2024-07-09T07:05:12+00:00",
  "remoteAddr": "...",
  "user": "...",
  "app": "spreed",
  "method": "POST",
  "url": "/ocs/v2.php/apps/spreed/api/v4/room/<room>/participants",
  "message": "Failed sharing <room> with <user>, received status code 501\n{\"message\":\"User already invited\"}",
  "userAgent": "Mozilla/5.0 (Linux) Nextcloud-Talk v0.31.0",
  "version": "29.0.3.4",
  "data": {
    "app": "spreed"
  }
}

[nickvergessen]

• caused by [Bug]: Your web server is not properly set up to resolve "/ocm-provider/" warning after update to 27.1.4 server#41762
  the ocm-provider/ check does not allow/fallback to index.php/ocm-provider/

[nickvergessen]

• More ref at OCM Services server#39574 (comment)
• Potential workaround at OCM Services server#39574 (comment)
• And a patch at fix(OCM): Fix OCM provider discovery for servers without beautiful URLs server#41234

[nickvergessen]

Todo

• Rooms that made an invite are not recoverable
• Find out why the remote knows about the invite (notification etc) when it didn't work locally

[nickvergessen]

Patch

diff --git a/lib/Federation/CloudFederationProviderTalk.php b/lib/Federation/CloudFederationProviderTalk.php
index c49a64c20..b95b525fe 100644
--- a/lib/Federation/CloudFederationProviderTalk.php
+++ b/lib/Federation/CloudFederationProviderTalk.php
@@ -510,8 +519,15 @@ class CloudFederationProviderTalk implements ICloudFederationProvider {
                try {
                        return $this->invitationMapper->getByRemoteAndAccessToken($remoteServerUrl, $remoteAttendeeId, $sharedSecret);
                } catch (DoesNotExistException) {
-                       throw new ShareNotFound(FederationManager::OCM_RESOURCE_NOT_FOUND);
+                       if (!$this->addressHandler->urlContainProtocol($remoteServerUrl)) {
+                               try {
+                                       return $this->invitationMapper->getByRemoteAndAccessToken('https://' . $remoteServerUrl, $remoteAttendeeId, $sharedSecret);
+                               } catch (DoesNotExistException) {
+                               }
+                       }
                }
+
+               throw new ShareNotFound(FederationManager::OCM_RESOURCE_NOT_FOUND);
        }
 
        private function notifyAboutNewShare(IUser $shareWith, string $inviteId, string $sharedByFederatedId, string $sharedByName, string $roomName, string $remoteRoomToken, string $remoteServerUrl): void {

💭 Thoughts

• Either expect to receive it without protocol, then we should strip it from invites when they contain it
• Or we expect to receive with protocol, then we should add it to invites that are missing it

[nickvergessen]

I think expecting the protocol is the better idea going forward as that is what will be send.