CORS support in login v2 and OAuth2 flow

[salonikumawat28]

Context

I have created a NextCloud app which adds a file menu item in Files app. When you click this menu item, it opens our website. From this website, I want to login into NextCloud so that I can get credentials which I can use to download and upload files.

First step I did was using the hardcoded username:password and passed it in Authorization header to download and upload URLs which failed on CORS. I was able to resolve the CORS issues once I installed WebAppPassword and whitelisted my website.

As a second step, I replaced the hardcoded username:password with the login v2 flow and it failed on CORS. This was surprising as my website origin was already whitelisted in WebAppPassword and was working for download and upload URLs. As a temporary hack, I added @CORS annotation in the login v2 controllers and it worked on all URLs except login/v2/poll because it fails on preflight request as it's a POST call with json content type. To solve this, another temporary hack I did was to add preflight URL for login v2 flow.

As a third step, I tried the OAuth2 flow. Similar to second step, I faced CORS and preflight issues. As a temporary hack I added @CORS in apps/oauth2/lib/Controller/OauthApiController.php methods and added preflight URL route.

Problem

As these hacks were direct code changes in the NextCloud server code, I want to replace these hacks with a proper solution. Things I tried:

1. In my NextCloud app, I registered a Middleware to resolve the CORS issues. The problem is that the Middleware works only the URLs pointed to the app I wrote and it doesn't work on the login URLs. Even if it works somehow, it will not resolve the preflight issue as the preflight route is not present.

Feature request

1. Ask: Generic solution for CORS for NextCloud app developer

As a NextCloud app developer, we can't make changes in the NextCloud server. So what's the generic solution for NextCloud app developers to resolve CORS and preflight issues?

2. Ask: Update login flow documentation

As a NextCloud app developer, we rely on login flow documentations(Login v2, OAuth) which doesn't talk about CORS issues and how to resolve. This ask is to update the login flow documentation to cover such issues and ways to resolve them.

3. Ask: Extend WebAppPassword for login URLs

As WebAppPassword works for download and upload URLs, can you extend the WebAppPassword support for login flows (both login v2 and OAuth) as well?

[salonikumawat28]

I looked into similar issues like #3131 and all the solution attempts and temporary hacks mentioned in the issue were based on the suggested mentioned in the issue, NextCloud login v2 flow doc and NextCloud OAuth flow doc but I was not able to find a solution which doesn't involve changes in NextCloud server.

[salonikumawat28]

Gentle Reminde : Can someone help me into this ?

[salonikumawat28]

Can please someone help me on this issue?

[meltzow]

same problem here.

[juliusknorr]

I think for the Login Flow V2 controller it should be fine to set the @CORS annotation on the API endpoints, but I'm not fully sure if there would be any security implications by that.

For Oauth or CORS in general I think we should have some way so that admins can configure a potential allow list. Maybe we could start with just having a config.php option for this to set the header accordingly in

server/lib/private/AppFramework/Middleware/Security/CORSMiddleware.php

Line 134 in c8b7a23

$response->addHeader('Access-Control-Allow-Origin', $origin);

@julien-nc Didn't you also recently setup something with the oauth app?

[julien-nc]

@juliushaertl Not really, no. The only topic where it is currently possible to canonically deal with CORS headers is WebDAV endpoints (by adding a Sabre plugin like the WebAppPassword app does).

@salonikumawat28 By the way, out of topic, if you want to avoid having WebAppPassword as a dependency, you can easily implement a similar Sabre plugin in your app that will whitelist your website's domain.

IMO you can avoid dealing with CORS issues if you implement the login flow v2 or OAuth2 code flow using your website's backend which will be able to reach the "/token" endpoint. Once you get an OAuth token (or an app password), you can provide it to your frontend which can then use it for requests to WebDAV endpoints (CORS being dealt with by WebAppPassword).

But maybe you have a strong constraint to perform the auth flows entirely in the browser.

The integration_* apps implement the OAuth2 code flow (to connect to external services) using the NC backend to perform the last /token request.

So for you, the OAuth implementation would be:

• your website's frontend opens a new tab (or redirects) to the authorize endpoint
• after the users have authenticated in NC, they get redirected to the redirection URL which is handled by your backend
• your backend does the last /apps/oauth2/api/v1/token request to get the token
• the token is provided to your frontend which can then perform WebDAV requests

[meltzow]

Hi, I develop a open-source Progressive web app (PWA) for nextcloud deck. I want to use login v2 too, but I got the same CORS issue like described above.
I can't understand why the public Login Flow V2 controller doesn't have the @cors annotation. Currently I must "hack" my application and use native HTTP Request to solve the CORS issues. Because native HTTP ignore some security things.
Are they any plans to add the annotations in login flow v2? if no, why?
Thank you.

[beatles1]

I'm also confused by this, I've made a browser extension for someone else's Nextcloud app. I want to be able to use the login v2 flow but because my app is in a browser and respects CORS I can't without asking the user for full permission to the servers domain.

I don't understand why the login flow would be configured to only work for the same origin, I'd assume using it from other origins is one of the main reasons it exists. Of course this works fine from a mobile app or something which doesn't respect CORS but just not for client only webapps.

[Chalolennox]

Is someone still working on this? Honestly, this is an essential feature.