OCM Services

[ArtificialOwl]

Resolves #39001

• models IOCMProvider and IOCMResource to manage the OCM discovery API,
• replacing PHP file ocm-provider/index.php with the integration of OCMController in core/routes.php,
• Local OCM Provider can be set [1]
• cloud_federation_ali's capabilities updated to use OCMProvider,
• OCMDiscoveryService to centralize OCM Discovery Services,
• switching old call to ocm endpoint's using OCMDiscoveryService
• adding ocm discovery to the background job FederatedSharesDiscoverJob
• allow federation to accept self-signed certificates [2]
• compat 1.0-proposal1 and 1.0
• tests

[1] ./occ config:app:set core ocm_providers --value '\OCA\CloudFederationAPI\Capabilities' (default)
[2] 'sharing.federation.allowSelfSignedCertificates' => true, in config/config.php

[AndyScherzinger]

also looping in @glpatcern

[AndyScherzinger]

/backport to stable27

[AndyScherzinger]

/backport to stable26

[come-nc]

I also agree with @Altahrim that json_* calls should throw on error.

[come-nc]

What is this testing?

[ArtificialOwl]

it confirms the generated object fit the documentation, based on required values on some parameters.

[glpatcern]

Glad to see this was merged. What are your plans for a backport to Nextcloud 27 and 26?

[backportbot-nextcloud]

The backport to stable27 failed. Please do this backport manually.

# Switch to the target branch and update it
git checkout stable27
git pull origin stable27

# Create the new backport branch
git checkout -b fix/foo-stable27

# Cherry pick the change from the commit sha1 of the change against the default branch
# This might cause conflicts. Resolve them.
git cherry-pick abc123

# Push the cherry pick commit to the remote repository and open a pull request
git push origin fix/foo-stable27

More info at https://docs.nextcloud.com/server/latest/developer_manual/getting_started/development_process.html#manual-backport

[backportbot-nextcloud]

The backport to stable26 failed. Please do this backport manually.

# Switch to the target branch and update it
git checkout stable26
git pull origin stable26

# Create the new backport branch
git checkout -b fix/foo-stable26

# Cherry pick the change from the commit sha1 of the change against the default branch
# This might cause conflicts. Resolve them.
git cherry-pick abc123

# Push the cherry pick commit to the remote repository and open a pull request
git push origin fix/foo-stable26

More info at https://docs.nextcloud.com/server/latest/developer_manual/getting_started/development_process.html#manual-backport

[ChristophWurst]

Adds new APIs to lib/public so we need documentation.

[nickvergessen]

Seems like

server/lib/private/Setup.php

Line 540 in f174e4a

$content .= "\n RewriteCond %{REQUEST_FILENAME} !/(ocm-provider|ocs-provider|updater)/";

should have been adjusted as well and we need to trigger it during the update.

Additionally this breaks servers with index.php/… routes (default) ❓
The endpoint used to be /ocm-provider and with clean urls it still is. But when the server uses index.php/… routes, it is now actually moved to index.php/ocm-provider ?

Also https://docs.nextcloud.com/server/stable/admin_manual/installation/nginx.html need adjusting (and therefore needs to be mentioned in https://docs.nextcloud.com/server/stable/admin_manual/release_notes/upgrade_to_27.html

Since this was also backported to 26 (😕 ) also https://docs.nextcloud.com/server/stable/admin_manual/release_notes/upgrade_to_26.html needs to be adjusted.
It's very unfortunate to have a huge massive change like this in a normal patch release.

cc @sorbaugh

[sorbaugh]

@nickvergessen huge appreciation for leading the debugging effort 🙏 Will align with @ArtificialOwl to get this dealt with.

[ArtificialOwl]

Seems like

server/lib/private/Setup.php

Line 540 in f174e4a

$content .= "\n RewriteCond %{REQUEST_FILENAME} !/(ocm-provider|ocs-provider|updater)/";

should have been adjusted as well and we need to trigger it during the update.

If #40745 resolves the issue, as it add a line to the original .htaccess, we might not need to trigger anything.

Additionally this breaks servers with index.php/… routes (default) ❓ The endpoint used to be /ocm-provider and with clean urls it still is. But when the server uses index.php/… routes, it is now actually moved to index.php/ocm-provider ?

I were not able to reproduce this issue with patched instance.
Previously, default setup were fine and I could only reproduce the reported issue on an instance with configured htaccess.RewriteBase

Also https://docs.nextcloud.com/server/stable/admin_manual/installation/nginx.html need adjusting (and therefore needs to be mentioned in https://docs.nextcloud.com/server/stable/admin_manual/release_notes/upgrade_to_27.html

I am not even a user of nginx, i require help on this task; but it might just be an adjustment on a comment section.

[nickvergessen]

I am not even a user of nginx, i require help on this task; but it might just be an adjustment on a comment section.

Me neither, but basically you replicate the change from htaccess and the Setup class into the docs. All needed patterns should be there already.

[kesselb]

Additionally this breaks servers with index.php/… routes (default) ❓
The endpoint used to be /ocm-provider and with clean urls it still is. But when the server uses index.php/… routes, it is now actually moved to index.php/ocm-provider ?

Yep, also reported via support.

I fear this pull request unintentional added hard requirement for apache's mod_rewrite.

[kesselb]

Yep, also reported via support.

I fear this pull request unintentional added hard requirement for apache's mod_rewrite.

Sorry, I mixed something up.

The new ocm-provider should also work without mod_rewrite.
That's done by using ErrorDocument 404 /index.php/error/404.
To allow overriding ErrorDocument in .htaccess we need at least AllowOverride FileInfo.

[AndyScherzinger]

So ignore your comment or something we need to take action on @kesselb

[nickvergessen]

I have the issue every time on my dev instance. federation is not working until I ran occ maintenance:update:htaccess after installing the server.

[nickvergessen]

The following patch makes it work again:

diff --git a/lib/private/Federation/CloudFederationProviderManager.php b/lib/private/Federation/CloudFederationProviderManager.php
index ea2f0dd7575..4e2a559ce8a 100644
--- a/lib/private/Federation/CloudFederationProviderManager.php
+++ b/lib/private/Federation/CloudFederationProviderManager.php
@@ -116,6 +116,7 @@ class CloudFederationProviderManager implements ICloudFederationProviderManager
                try {
                        $ocmProvider = $this->discoveryService->discover($cloudID->getRemote());
                } catch (OCMProviderException $e) {
+                       $this->logger->debug($e->getMessage(), ['exception' => $e]);
                        return false;
                }
 
diff --git a/lib/private/OCM/OCMDiscoveryService.php b/lib/private/OCM/OCMDiscoveryService.php
index ac9bf2a3965..10d460b34da 100644
--- a/lib/private/OCM/OCMDiscoveryService.php
+++ b/lib/private/OCM/OCMDiscoveryService.php
@@ -105,6 +107,9 @@ class OCMDiscoveryService implements IOCMDiscoveryService {
                                'exception' => $e,
                                'remote' => $remote
                        ]);
+                       if (!str_ends_with($remote, '/index.php')) {
+                               return $this->discover($remote . '/index.php', $skipCache);
+                       }
                        throw new OCMProviderException('error while requesting remote ocm provider');
                }
 

[nickvergessen]

I'm not sure what exactly ErrorDocument 404 /index.php/error/404 does, but yeah with that line in .htaccess the request seems to work.

[nickvergessen]

Simply always requesting index.php also works (tested with our instance and locally), so I sent that as a patch in #41234

[kesselb]

I'm not sure what exactly ErrorDocument 404 /index.php/error/404 does, but yeah with that line in .htaccess the request seems to work.

It tells apache2 to forward a 404 error to our index.php to handle it.
Our implementation then maps the request to the actual ocm-controller.

I haven't heard back from the customer, but I assume that they have AllowOverride None and therefore the ErrorDocument in .htaccess has no effect.