-
Notifications
You must be signed in to change notification settings - Fork 669
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Wizard: 301 'Moved Permanently' redirection is not being followed #5954
Comments
FYI @ogoffart for discussion |
Will be fixed by: #6009 |
@SamuAlfageme Thanks for the pointer, I'll check whether my patch does indeed address this. |
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. |
@ckamm you're absolutely right. I forgot the original reason of the issue.
IMO, we should go for this, yup 👍 |
@SamuAlfageme Now there's a PR for it :) |
Grab any permanent redirects from the base url the user entered before attempting to connect to a modified url (with status.php added).
Grab any permanent redirects from the base url the user entered before attempting to connect to a modified url (with status.php added).
Grab any permanent redirects from the base url the user entered before attempting to connect to a modified url (with status.php added).
@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)
Unsuccessful scenario
|
Hrm. We could query and use the base-url redirect only if the base-url/status.php request fails. |
@SamuAlfageme Please test the new PR! |
Unfortunately checking the base-url for redirects in all cases lead to incorrect behavior in some SAML/OAuth2 edge cases. This new iteration checks the base url for redirects only if the standard CheckServerJob can't reach the server. That way the 2.3 behavior is only changed in cases that would have lead to errors. See #5954
Unfortunately checking the base-url for redirects in all cases lead to incorrect behavior in some SAML/OAuth2 edge cases. This new iteration checks the base url for redirects only if the standard CheckServerJob can't reach the server. That way the 2.3 behavior is only changed in cases that would have lead to errors. See #5954
@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. |
@ckamm yeah, I think the problem was not in the end related with this issue but with specific (and stricter) firewall configs. My mistake. |
@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. |
Ticket for reference: #6135 |
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 theLocation
header. Error is displayed.Expected behavior
The client should be able to follow a redirection chain.
Steps to reproduce
The text was updated successfully, but these errors were encountered: