Skip to content
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

Workaround to check htaccess in case of redirects #25331

Merged
merged 1 commit into from Jul 11, 2016

Conversation

PVince81
Copy link
Contributor

@PVince81 PVince81 commented Jul 1, 2016

In some setups, the web server will redirect any call to "data/" to the
main page. This causes the XHR to return the 200 HTTP status code and
the body contains the HTML page of the main page / files app.

This fix improves the htaccess failure detection by adding a known
string inside the test file "htaccesstest.txt". If we are able to find
this string, it means that the web server didn't block access to that
file.

Reported by greysun on IRC.

Please review @RealRancor @LukasReschke @danimo @DeepDiver1975 @guruz @georgehrke

Would be good to backport this to 9.1 and 9.0 to avoid annoying false positives.

In some setups, the web server will redirect any call to "data/" to the
main page. This causes the XHR to return the 200 HTTP status code and
the body contains the HTML page of the main page / files app.

This fix improves the htaccess failure detection by adding a known
string inside the test file "htaccesstest.txt". If we are able to find
this string, it means that the web server didn't block access to that
file.
@PVince81 PVince81 added this to the 9.2-next milestone Jul 1, 2016
@ghost
Copy link

ghost commented Jul 1, 2016

Mhhh, why adding the HTACCESSFAIL:? There is already a unique and known test within the htaccesstest.txt

@PVince81
Copy link
Contributor Author

PVince81 commented Jul 1, 2016

@RealRancor because the JS side needs to check whether the 200 response contains that string.
There are some cases where a 200 OK is valid whenever the server redirects from "data/htaccesstest.txt" to "apps/files". In this case we do get a response, but it's not the file itself.

This happens in greysun's environment. We can't detect 302 redirects with XHR/ajax as the browser will automatically follow redirects.

@PVince81
Copy link
Contributor Author

PVince81 commented Jul 1, 2016

@RealRancor also I didn't want to copy the whole exact test text to the JS side in case someone decides to change it in the future... a bit risky to expect an exact match.

@LukasReschke
Copy link
Member

LukasReschke commented Jul 1, 2016

Nextcloud already has a patch for this in all releases. Didn't test the ownCloud patch but it looks pretty similar and should do it's work. 👍 for the approach itself.

Ref nextcloud/server#91
Ref nextcloud/server#92

@PVince81
Copy link
Contributor Author

PVince81 commented Jul 1, 2016

@LukasReschke I think there's a slight risk if one day someone changes the message in one place but not in the other. In this case people might get false positives that their server is safe when it's not.

That why I opted for adding "HTACCESSTEST" instead with a comment. Also this has the advantage that the message is only in one place.

@PVince81
Copy link
Contributor Author

PVince81 commented Jul 1, 2016

also: slight risk in case of newlines, if fwrite would add one, not sure if it does...

@PVince81
Copy link
Contributor Author

PVince81 commented Jul 1, 2016

  • TODO: adjust unit test

@ghost
Copy link

ghost commented Jul 1, 2016

also I didn't want to copy the whole exact test text to the JS side in case someone decides to change it in the future... a bit risky to expect an exact match.

Ahhh, i didn't know that. My question above was based on the assumption that you could only match partially for e.g. This is used for testing whether htaccess.

When thinking about it the HTACCESSFAIL is also a better approach as the changes that this text got changed is less likely.

@ghost
Copy link

ghost commented Jul 9, 2016

Fixes #25416

@PVince81
Copy link
Contributor Author

This was tested by greysun on IRC, counting as 👍

@PVince81
Copy link
Contributor Author

stable9.1: #25434
stable9: #25435

@ghost
Copy link

ghost commented Jul 11, 2016

Also confirmed to work here: https://forum.owncloud.org/viewtopic.php?f=38&t=37580#p119487

@PVince81
Copy link
Contributor Author

Damn, I didn't see that JS tests were failing.

Will send a follow up PR

@PVince81
Copy link
Contributor Author

Here we go #25439

@lock
Copy link

lock bot commented Aug 5, 2019

This thread has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.

@lock lock bot locked as resolved and limited conversation to collaborators Aug 5, 2019
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

2 participants