-
Notifications
You must be signed in to change notification settings - Fork 2.1k
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
oc-1875 : running OwnCloud on an alias (or not) with Nginx [the real one] #385
Conversation
Can one of the admins verify this patch? |
This is ok to test |
Unit Tests are no longer executed. |
Thanks again for the patch. Can you document your code a bit more so that it is easier to understand what you want to do here? Also the -13 smells as you rely on having ownCloud installed in a specific folder or a specific host. You shouldn´t do that. The Url is completely flexible. |
Hum sorry,
is similar to
But I did a mistake when applying my patch, I replace new code (based on DIR path, written by another than me) by old code (based on FILE path, written by another than me) :
which is similar to
Perhaps we need to revert this line. That was not my idea, the previous code does this, this is the only part I don't modified. @karlitschek : |
@@ -119,25 +119,26 @@ public static function autoload($className) { | |||
|
|||
public static function initPaths() { | |||
// calculate the root directories |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
imagine your httpd document root is '/var/www'
→ requesting /index.html serves /var/www/index.html
imagine you have an alias named 'alias'
→ requesting /alias/index.html serves /var/www/index.html
imagine you put owncloud on a subdir named 'dir'
→ requesting /alias/dir/index.html serves /var/www/dir/index.html
Sorry. I don´t want annoy you but I meant documentation of the code of course. Not only in the pull request. |
I do not use my computer right now, I will comment the code later. Have you seen my comments I made on GitHub? |
Yes. I think this is understandable. Thanks a lot. |
I tested it and it works in all the scenarios that I have here. This is fragile code and it is possible that this doesn´t work in other, more esoteric environments. But this is something that we see when the code is in master. So a +1 from me for now if you add the documentation. Thanks a lot :-) +1 |
@illwieckz |
There is a use case I've not tested, it's reverse proxying like in #250, when user request 'GET /alias/index.php' to the reverse proxy, but owncloud receive 'GET /index.php'. I do not know what happens in this case. @karlitschek : @DeepDiver1975 : @ALL : Edit : I wrote this code to have it functionnal with apache without changing habits of apache users, other httpd servers should perhaps emulate the behavior of apache, I can say how to do it with Nginx and fastcgi. |
@illwieckz Yes. I think it is useful to make it possible to define the webroot, host, port and protocol in config.php for the cases that the automatic detection fails. Please also see this pull request #208 from @herbrechtsmeier Perhaps we can merge this somehow. |
imho defining the webroot would be great for general web server and do not need to make some custom configuration only for url |
I'll try to write "defining webroot in config.php" in another branch, and if it works I'll do another pull request. |
The test are failing because $_SERVER["SCRIPT_NAME"] is set to '/usr/bin/phpunit' and as a result OC::$WEBROOT is '/usr/bin/phpunit' as well. I think in the old code following lines implicitly caught this situation: @illwieckz Can you please take care of this? THX |
@illwieckz ping ;-) THX |
sorry, it's hard to keep up (because job IRL ^^)
$_SERVER["SCRIPT_NAME"] must contain a path to a .php script, not the name of a binary (interpreter ?). Because phpunit is a tool used to debug, I think it's a very bad idea to write code to workaround phpunit bugs, it's like bypassing a debugger, who do this ? Example with a correct interpreter :
It can't, this code works only if $_SERVER["SCRIPT_NAME"] end with a '/' character, but '/usr/bin/phpunit' end with a 't' character. Also, '/usr/bin/phpunit/index.php' can't be a good $_SERVER["SCRIPT_NAME"], it must be something like '/var/www/index.php' (it depends of your configuration). The code you pointed ensures $_SERVER["SCRIPT_NAME"] contains the 'index.php' script name if we request '/' with a http server configured to serve "index.php" as Index, and if the http server is buggy or misconfigurated and fill $_SERVER["SCRIPT_NAME"] with dirname instead of scriptname. |
I did a quick search on this topic - for me it looks like setting $_SERVER["SCRIPT_NAME"] to phpunit is done on purpose. We should set $_SERVER["SCRIPT_NAME"] within out bootstrap code to the correct value (tests/bootstrap.php). @icewind1991 Any objections? THX |
@illwieckz rebase please and I'll try to get phpunit up and running |
Yes I think phpunit must set $_SERVER variable before running the php script, and it must test several values.
The config parameters are a good answer, at least to be able to use owncloud without patching the code when using it on an exotic setup which breaks autodetection. I'll rebase tonight |
Sorry for not being able to do it sooner! I just rebase. |
@owncloud-bot retest this please |
Four things :
|
in fact, five things :
|
Hi @illwieckz Can you check if this can be fixed with the new config options, overwritehost, overwriteprotocol, overwritewebroot, overwritecondaddr ? Thanks |
I will look at it, yes! |
@illwieckz Any news here? :-) |
I think the root problem here is that there are so many potential entry points into the code, ie it's acceptable to reference random .php scripts all around the filesystem? I concede less experience with PHP, but were I writing this in perl/ruby I would have a single entry point into the code, which in turn talks to a "url router" and that would then have the job to map urls forward/backward to controller actions. So the only tiddle-able that I would need is the base-uri and everything else falls out from that It seems that perhaps we can get there really easily though:
Now we get nice looking urls and most of the guesswork disappears from the code? |
please reopen if this is not fixed with the new config options, overwritehost, overwriteprotocol, overwritewebroot, overwritecondaddr |
This Pull Request is a similar to #22 (the #22 could be deleted).
This is another attempt to do things properly.
I hope this Pull Request is clean and done properly :
For my first "Pull Request" attempt I wrote something like this :
¹ Nginx or other HTTPd server