Support pretty URLs

[LukasReschke]

This changeset allows ownCloud to run with pretty URLs, they will be used by default if mod_rewrite and mod_env are available. This means basically that the index.php in the URL is not shown to the user anymore.

Also the not deprecated functions to generate URLs have been modified to support this behaviour, old functions such as filePath will still behave as before for compatibility reasons.

Examples:
http://localhost/index.php/s/AIDyKbxiRZWAAjP => http://localhost/s/AIDyKbxiRZWAAjP
http://localhost/index.php/apps/files/ => http://localhost/apps/files/

Due to the way our CSS and JS is structured the .htaccess uses some hacks for the final result but could be worse... And I was just annoyed by all that users crying for the removal of index.php ;-)

@karlitschek @DeepDiver1975 Please decide if this is something we want to have. If yes I'll see how we could best unit-test this…

Fixes #5744

Fixes #12345

[LukasReschke]

This is obviously only for Apache as I have no idea at all how to use or configure other webservers ;-)

[LukasReschke]

To test enable mod_rewrite and mod_env, things should work magically. Old URLs with index.php will still work and not get redirected since I didn't want to have too many things exploding.

[LukasReschke]

Please notice that supporting this obviously also requires twice as much QA ;-)

(i.e. on a server with mod_rewrite installed and another one without)

[LukasReschke]

Black voodoo because there is no static folder (as in most frameworks such as Symfony) and thus we have to do that guessing here.

[oparoz]

Subscribing

[DeepDiver1975]

great initiative @LukasReschke THX

I already did introduce a config flag for removing index.php from the generated urls - maybe you can reuse this one - https://github.com/owncloud/core/blob/use-pretty-urls/lib/private/urlgenerator.php#L70

[LukasReschke]

I already did introduce a config flag for removing index.php from the generated urls - maybe you can reuse this one - https://github.com/owncloud/core/blob/use-pretty-urls/lib/private/urlgenerator.php#L70

I think it would make more sense if we stick with the automatic approach implemented here instead of relying on some configuration switch. As far I understand most people don't change anything in the config and neither do we devs, so if something is standard in most environments it gets automatically better tested. But we can also make this a configuration only option if desired.

[shoeper]

To follow this automatic approach we could add a rewrite rule to the nginx config in the manual and set an env to detect the redirect rule.
see http://stackoverflow.com/questions/8098927/nginx-variables-similar-to-setenv-in-apache
Something like

rewrite ...
env[REMOVE_INDEX_PHP] = true

[RobinMcCorkell]

The nginx configuration is very simple, and in fact doesn't need any rewrites at all. I'm using:

try_files $uri $uri/ /index.php?$query_string;
location ~ \.php(?:$|/) {
    fastcgi_split_path_info ^(.+?\.php)(/.+)$;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_pass ...;
}

However, getting that environment variable into PHP-FPM is proving difficult. I tried fastcgi_param in my nginx config and `env[modRewriteWorking] = true' in PHP-FPM's config, but neither worked. I know that with the above nginx config, pretty URLs work (I manually removed index.php from the URL bar), but that worked before this PR too.

I think @DeepDiver1975 's suggestion of using a config.php variable is the best. It makes it much easier for other web servers, and is actually easier to set that way. I know we lose the automatic aspect, but setting something in config.php is easy, while setting something in PHP-FPM or nginx.conf (and even then I don't know what) is more difficult.

[shoeper]

Setting the env in the config wouldn't be an issue if possible because most
users will just copy the nginx config from owncloud manual.

But a config setting would be enough. In my opinion people not being able
to just set a config option shouldn't run owncloud because they aren't able
to assess risks and won't be able to securely setup their installation.

Am 11. Februar 2015 19:31:40 schrieb Robin McCorkell
notifications@github.com:

The nginx configuration is very simple, and in fact doesn't need any
rewrites at all. I'm using:

try_files $uri $uri/ /index.php?$query_string;
location ~ \.php(?:$|/) {
    fastcgi_split_path_info ^(.+?\.php)(/.+)$;
    fastcgi_param SCRIPT_FILENAME $document_root$fastcgi_script_name;
    fastcgi_param PATH_INFO $fastcgi_path_info;
    fastcgi_pass ...;
}

However, getting that environment variable into PHP-FPM is proving
difficult. I tried fastcgi_param in my nginx config and
`env[modRewriteWorking] = true' in PHP-FPM's config, but neither worked. I
know that with the above nginx config, pretty URLs work (I manually removed
index.php from the URL bar), but that worked before this PR too.

I think @DeepDiver1975 's suggestion of using a config.php variable is the
best. It makes it much easier for other web servers, and is actually easier
to set that way. I know we lose the automatic aspect, but setting something
in config.php is easy, while setting something in PHP-FPM or nginx.conf
(and even then I don't know what) is more difficult.

---

Reply to this email directly or view it on GitHub:
#14081 (comment)

[DeepDiver1975]

Guess what? Doesn't work for me 🙊

[LukasReschke]

As discussed with @DeepDiver1975 we can use the automatic approach since this will lead to problems in some deployment scenarios and our goal is to be as easy to install as possible.

Thus I migrated this to the front_controller_active config setting which defaults to false and added some documentation in config.sample.php and .htaccess

[josh4trunks]

@mitar @MorrisJobke The documented nginx config already has the following

index index.php;
try_files $uri $uri/ /index.php;

I don't see a reason to include index.html/index.htm when these aren't present very often in owncloud, and as far I know owncloud doesn't use arguments so the try_files line we have is fine as is. Finally if you are going to use args with nginx the cleanest way is index.php$is_args$args

[mitar]

The point is that the resulting URL is just internal, so /index.php?$args is good enough, no?

OwnCloud might not use them, but plugins might?

[mitar]

So there is no need to provide $uri to index.php?

[josh4trunks]

As I stated, "/index.php" is already in the documented nginx config. and try_files doesn't "provide" $uri to index.php, it tries the provided uri, uri with a slash (which would check "$uri/index.php"), then finally redirects to the main /index.php page.

But if apps do use arguments we should replace "/index.php" with "/index.php$is_args$args" in the try_files line in the documented config.

[stevenmirabito]

Here's my go at a working Nginx configuration: https://gist.github.com/stevenmirabito/5560ba2feea9eeb32db1

I've been ironing out the kinks and everything seems to be working on my installation. I did have a problem with the change to core/js/js.js however - POST requests without /index.php/ in the URL will fail as you can only rewrite GET or HEAD requests, and the requests need to be made through index.php for everything to load properly. I'm not sure how this is working on Apache with the given configuration, unless I'm doing something completely wrong in mine, but for now I've reverted that change to my installation.

Unfortunately, due to the way ownCloud is set up, a simple try_files statement won't work here - requesting https://myowncloud.tld/apps/files/ will load that directory directly as it exists in the file structure instead of through index.php. As a result, I had to resort to messy regex whitelisting to reproduce what was accomplished in the committed .htaccess.

Let me know if anyone has any questions or suggestions. Hope this helps!

[josh4trunks]

@stevenmirabito what are you trying to accomplish? hiding index.php from the URL?
so a client can connect to /apps/files instead of /index.php/apps/files?

[josh4trunks]

@mitar I just realized what you were trying to say earlier, my mistake you were trying to pass the uri to index.php, not just arguments, (I missed that part!)

so @stevenmirabito you tried try_files $uri $uri/ /index.php$uri

[stevenmirabito]

@josh4trunks Yes, that's the entire point of this pull request. @LukasReschke provided the Apache mod_rewrite config, what I posted above is for Nginx.

Like I said, I did try a try_files directive, but it won't work here because what that does is looks to see if the file actually exists, then passes it to index.php if it doesn't. For ownCloud, the files do exist, so that directive will not work (for example, requesting /apps/files/ will prompt Nginx to try to load /apps/files/index.php, which it will load directly as that file exists instead of through index.php).

[guidtz]

Hello,
I have an installation with Debian 8 / Apache 2.4 and Owncloud 8.2.2 but index.php stell apear in url.
There is a solution in this version or we have to wait 9.0 version ?

Thanks

[DeepDiver1975]

This is a New feature of 9.0

[ghost]

@josh4trunks @stevenmirabito @mitar Let's move the discussion about the needed changes in the nginx config to owncloud-archive/documentation#2014

Havn't noticed your posts in here and that info could be really useful there.

[thejustsoul]

This is a New feature of 9.0

How to enable this for Apache2? To automatically (maybe 302 redirect?) used the URL:
https://localhost.tld/index.php/s/AIDyKbxiRZWAAjP => https://localhost.tld/s/AIDyKbxiRZWAAjP
https://localhost.tld/index.php/settings/admin => https://localhost.tld/settings/admin
etc..
And to "share" file, the link was without index.php in the address.

[pandorra2]

huh, did i get all of you wrong?
the only yet implemented solution ive found is this one, well documented in the 9.0 manual:
https://doc.owncloud.org/server/9.0/admin_manual/configuration_server/config_sample_php_parameters.html
(ctrl+f RewriteBase)

so i've added 'htaccess.RewriteBase' => '/', to my config. well, doesn't work - right as the manual warns already. still have to run that occ command maintenance:update:htaccess
but: occ doesn't feature the command referenced to....... -.-
error =>

[Symfony\Component\Console\Exception\CommandNotFoundException]
There are no commands defined in the "maintenance:update" namespace.
Did you mean one of these?
maintenance:mimetype
maintenance

also i tried to add 'front_controller_active' => true, to the config despite only place this param gets mentioned is right here...

tl;dr
tried all the fixes in here and
...index.php/apps/files/ works as well as .../apps/files/
but every link within owncloud still directs to ...index.php/apps/files/

is this behavior right as it should be of today or did i miss something?

[RobinMcCorkell]

@pandorra2 That command, and the config.php option, will only available in 9.0.3 and above

[eppfel]

@pandorra2 @thejustsoul I found that mod_env was restricted to a whitelist, so 'front_controller_active' was not set, although mod_rewrite was active.
I was able to get it working with fiddling in the source code. More here #24972

[PVince81]

With all the information here, I'm confused again how to setup 9.0.2 to remove index.php and also 9.0.3.

Can someone provide step by step instructions on how to setup 9.0.2 (without front_controller_active) and 9.0.3 to make it work, also in update cases ? This is important for update testing and to make packaging properly compatible (see #23512)

Thanks.

[PVince81]

So, I did some tests and here is the result: owncloud-archive/documentation#2205 (comment)

It seems that having a writable ".htaccess" with properly configured web server for ".htaccess" seems to be enough. Installing or upgrading ownCloud would maintain the proper values there.

Next step: figure out what, how and why to use "front_controller_active" and also add info in the doc ticket.

[PVince81]

Ok, turns out there are some docs here: owncloud-archive/documentation#2431

[basert]

After enabling this, everything works fine except ajax "drap&drop" uploads. The POST request calls <DOMAIN>/apps/files/ajax/upload.php, the error log contains

2016/07/02 17:34:35 [error] 23529#23529: *282 FastCGI sent in stderr: "PHP message: PHP Fatal error: Uncaught Error: Class 'OC' not found in /var/www/owncloud/apps/files/ajax/upload.php:36 Stack trace: #0 {main} thrown in /var/www/owncloud/apps/files/ajax/upload.php on line 36" while reading response header from upstream, client: IP, server: HOST, request: "POST /apps/files/ajax/upload.php HTTP/1.1", upstream: "fastcgi://unix:/run/php/php7.0-fpm.sock:", host: "HOST"

When I disable fastcgi_param front_controller_active true everything works as expected and the file gets uploaded.

[josh4trunks]

@basert upload.php shouldn't be one of the scripts owncloud executes. Are you using nginx? If so it sounds like your config isn't correct for owncloud 9. Can you post it so I can take a look.

[basert]

Sure, thanks, here's a GIST of my config:
https://gist.github.com/basert/ca9dde89f3c5a54c604c25afc80f7cea

[ghost]

@basert You shouldn't use such an older Pull Request for such questions / issues. Either create a new issue if you think there is a bug within this feature or ask for support at either the users malinglist or the forums (see https://owncloud.org/support).

But just had a short look at your nginx config which doesn't match the config provided here:

https://doc.owncloud.org/server/9.0/admin_manual/installation/nginx_owncloud_9x.html#owncloud-in-the-webroot-of-nginx

This one is known to work with the pretty urls.

[Delagen]

+1 for config for apache