Client: Wizard: 301 'Moved Permanently' redirection is not being followed

[SamuAlfageme]

Actual behavior

The client appends /status.php and /owncloud/status.php to the shortened entrypoint URL, which results on a 404 since that resource was moved permanently to the URL on the Location header. Error is displayed.

Expected behavior

The client should be able to follow a redirection chain.

Steps to reproduce

1. Create a short URL to an ownCloud instance using e.g. https://goo.gl
2. Try to connect using the short URL

[SamuAlfageme]

Connected to https://github.com/owncloud/client/issues/5553 (that scenario works though) - this one is about only the "entrypoint" (server URL) being behind the redirection - does fixing this make sense?

cc/ @ckamm

[guruz]

FYI @ogoffart for discussion
I guess it would make sense.

[SamuAlfageme]

Will be fixed by: https://github.com/owncloud/client/pull/6009

[ckamm]

@SamuAlfageme Thanks for the pointer, I'll check whether my patch does indeed address this.

[ckamm]

No, this is actually an independent issue. The issue here is that when the user enter http://foo the client queries http://foo/status.php. Url shorteners don't forward subpaths, so this url will actually be a 404!

Suggestion: In the wizard only, start off by querying the url the user entered and handle permanent redirects. Only then change the path to look for the owncloud instance.

[SamuAlfageme]

@ckamm you're absolutely right. I forgot the original reason of the issue.

start off by querying the url the user entered and handle permanent redirects

IMO, we should go for this, yup 👍

[ckamm]

@SamuAlfageme Now there's a PR for it :)

[SamuAlfageme]

@ckamm I just saw a SAML scenario where this broke OAuth2 workflow. Probably the _edgiest case of them all_ but might ask for a revert of this 😕

Successful scenario (what we used to do)

1. Client checks https://<server>/status.php (200) and then https://<server>/remote.php/webdav/ (which includes the WWW-Authenticate: Bearer realm="ownCloud")

Unsuccessful scenario

1. Client checks https://<server>/ -> server replies 302; location: https://<server>/<IDP>
2. Redirection is followed and the client launches the WebView before the WWW-Authenticate: Bearer realm="ownCloud" is received (which does not always happens)

[ckamm]

Hrm. We could query and use the base-url redirect only if the base-url/status.php request fails.

[ckamm]

@SamuAlfageme Please test the new PR!

[SamuAlfageme]

@ckamm apparently the WWW-Authenticate headers are only replied by the server when doing a PROPFIND to the DAV endpoint, we're currently doing a GET and that's why we were following the SAML redirection.

I think we'd need to switch to PROPFIND cc/ @ogoffart

[ckamm]

@SamuAlfageme Did you test the version that has my adjustments? The behavior shouldn't change at all from 2.3.3 with the current approach.

[SamuAlfageme]

@ckamm yeah, I think the problem was not in the end related with this issue but with specific (and stricter) firewall configs. My mistake.

[ckamm]

@SamuAlfageme Okay. We probably want to make that work for 2.4 even if it's not a regression: could you make a new ticket about it and describe how to reproduce? There's no guarantee we can get this to work within the backwards-compatibility constraints though.

[SamuAlfageme]

Ticket for reference: https://github.com/owncloud/client/issues/6135