AppEcosystem Authentification

[bigcat88]

• Adds: new way of authentication for external applications.

Summary

It's a draft for tomorrow's AppEcosystem call.
This is all that is needed (minimum changes) to authenticate applications that will be written for the new Appecosystem.

It is desirable that before the next releases this would already be included, starting from the 26th version of the cloud. (AppEcosystem is developed only for 26+ versions)

TODO

• Nothing, we had tested it for two month, here will be no changes, it is enough for this.

Checklist

• Code is properly formatted
• Sign-off message is added to all commits
• Tests (unit, integration, api and/or acceptance) are included
• Screenshots before/after for front-end changes
• Documentation (manuals or wiki) has been updated or is not required
• Backports requested where applicable (ex: critical bugfixes)

[juliusknorr]

As talked in the call, i think the cleanest approach would be be to have a AuthenticationProvider interface that apps can implement an register their authentication services then, however since there are plans to move this to OCP anyways it might be ok for now to:

• Add the unknown class as a stub for psalm
• Wrap the Server::get with a try/catch as DI might still fail
• Leave a hint for furture code readers about the reasoning

[AndyScherzinger]

/backport to stable27

[julien-nc]

👍

[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