Remove index.php from urls

[cjoy]

Hi,

How would I go about removing index.php from the url?

I've tried adding 'htaccess.RewriteBase' => '/', to config.php and then running sudo nextcloud.occ maintenance:update:htaccess, but I get the following error:

The process control (PCNTL) extensions are required in case you want to interrupt long running commands - see http://php.net/manual/en/book.pcntl.php
Error updating .htaccess file, not enough permissions?

[kyrofa]

The .htaccess being writable seems to be a requirement for this to work, however, as a side-effect of being in a snap, it's read-only (and disabled anyway for performance reasons). There might be things we could do on the Apache side, but the necessary changes don't appear to be documented anywhere.

[d1rk]

@kyrofa i see your point, but (just digging into this) I expect the apache config to be read-only, too. It is also inside the snap, am I right?

If we can control the scenario were in, because in a snap it should be in a state we defined, can't we just enable this feature by default?

[kyrofa]

If we can control the scenario were in, because in a snap it should be in a state we defined, can't we just enable this feature by default?

You're right that the snap is in a state we've defined, and like I said I bet there are things we could do to make this work, but I have the same concerns I had back when #115 was raised: there have been issues caused by this in the past, and it's not something that Nextcloud enables by default, so I'm not sure we should either. We could hide it behind a switch, but again, that requires us to know what modifications we need to make.

[d1rk]

@kyrofa Thanks for pointing me. Since people are interested in this, how do we go forward? Is there a list of issues related to this feature and/or a strategy how to solve those?

[d1rk]

Could one not use a functionality similar to this, to enable such a feature? https://github.com/nextcloud/nextcloud-snap/pull/416/files

[kyrofa]

Yeah I was thinking the same. However, I don't actually know what changes are done in the .htaccess (which we'll need to make in Apache instead) to make this work.

[d1rk]

@kyrofa Thanks for your time. I really appreciate that. The .htaccess is being included in the apache configuration, like this:

https://github.com/nextcloud/nextcloud-snap/blob/master/src/apache/conf/httpd.conf#L130

Therefore, i expect there is nothing but the assertion, if the file is writable needs to be 'changed'. The only thing within the .htaccess file that needs to be changed (or even not) is the RewriteBase Directive. But since you connect the entire Domain against your nextcloud with this, it should be left untouched with '/'.

[kyrofa]

The typical process to enabling this looks something like this as far as I understand:

sudo nextcloud.occ config:system:set htaccess.RewriteBase --value="/"
sudo nextcloud.occ maintenance:update:htaccess

The .htaccess is being included, yes, but it's not writable. As a result, the second step above will, I assume, be met with failure. Since it can't modify the .htaccess, we'll need to figure out what modifications it would have made, and make them straight in Apache instead.

[d1rk]

I just ran these:

sudo nextcloud.occ config:system:set htaccess.RewriteBase --value="/" returned System config value htaccess.RewriteBase set to string / successfully.

sudo nextcloud.occ maintenance:update:htaccess returned Error updating .htaccess file, not enough permissions, as expected.

The later would only change, as stated above, that the RewriteBase would be set to '/'. (which I think is the default, anyway?)

[kyrofa]

Wait, so maintenance:update:htaccess just takes the htaccess config and applies it?

[kyrofa]

i.e. step 1 does nothing without step 2?

[d1rk]

@kyrofa AFAIK that's correct.

[d1rk]

@kyrofa Thanks for the time, you put into that. How do you think do we continue on this?

[benjamingwynn]

+1 although it makes sense this isn't the default behaviour, some document working commands to enable this as a preference would be awesome

[RenatoXSR]

+1
Nextcloud manual recommends running "occ maintenance:update:htaccess", so "nextcloud.occ maintenance:update:htaccess" should be able to write to disk. Maybe we could create a config in the snap, just like changing ports, that would make this work.

[Moekr]

A nginx reverse proxy and some tricky configuration can remove the index.php imperfectly.
This is my configuration:

server {
	listen 80 default_server;
	listen [::]:80 default_server;
	server_name nextcloud.com;
	return 301 https://nextcloud.com$request_uri;
}

server {
	listen 443 ssl http2 default_server;
	listen [::]:443 ssl http2 default_server;
	server_name nextcloud.com;

	ssl on;
	ssl_certificate /etc/nginx/ssl/nextcloud.com/fullchain.cer;
	ssl_certificate_key /etc/nginx/ssl/nextcloud.com/nextcloud.com.key;

	ssl_stapling on;

	# static content
	location ~ ^.*\.(css|js|svg|png|jpg|jpeg|ico|ttf|woff|json|html)$ {
		proxy_pass http://localhost:8101;
	}

	# redirect
	location ~ ^/index\.php/(.*)$ {
		if ($request_method = "POST") {
			proxy_pass http://localhost:8101;
			break;
		}
		return 301 https://nextcloud.com/$1$is_args$args;
	}

	# uri with php
	location ~ ^.*\.php/.*$ {
		proxy_pass http://localhost:8101;
		sub_filter_types application/json;
		sub_filter "\/index.php\/" "\/";
	}

	# rewrite
	location / {
		rewrite ^ /index.php$uri break;
		proxy_pass http://localhost:8101;
		proxy_redirect https://nextcloud.com/index.php/ https://nextcloud.com/;
		proxy_redirect /index.php/ /;
		sub_filter_once off;
		sub_filter "<a href=\"/index.php/" "<a href=\"/";
		sub_filter "<a href=\"https://nextcloud.com/index.php/" "<a href=\"https://nextcloud.com/";
	}

	client_max_body_size 1024m;

	include /etc/nginx/proxy_params;
	include /etc/nginx/security_params;
}

Known issues:

1. The generated share links still contain index.php like "https://nextcloud.com/index.php/s/abcd" but actually this link will be redirected to "https://nextcloud.com/s/abcd", so when copy and share the share links the index.php section can be deleted.
   ps: these links seem to be generated in front end with some ajax requests, I tried to modify the ajax responses (sub_filter_types application/json; sub_filter "\/index.php\/" "\/";) but the links still not changed
2. some plugins may be not compatible with this configuration, such as a plugin using some relative links to load static resources

[szaimen]

Here is a working POC but it seems like it is too much of an hack to be considered as solution for this issue: #1700

[martindale]

Subscribed for updates on this issue, but seems as if in owncloud/core#5744, owncloud/core#14081, and many other forums scattered across the web that configuration of pretty URIs is still difficult and arcane knowledge.

[Gwindalmir]

I managed to figure it out, without mounting the snap read/write.

Disclaimer: this is the first snap I've ever worked with. I know pretty much nothing about them, so there's probably a better way than how I did it (once it's clear what exactly I did).

What I did was copy the .htaccess file from inside the snap, to the config directory, then used a bind mount to overlay the copy on top of the original, then restarted apache.

Here's the steps:
Copy the .htaccess file to a location you can write to:
sudo cp /snap/nextcloud/current/htdocs/.htaccess /var/snap/nextcloud/current/nextcloud/config/
Bind mount the .htaccess file back into the snap, this makes our changes readable by the snap:
sudo mount /var/snap/nextcloud/current/nextcloud/config/.htaccess /snap/nextcloud/current/htdocs/.htaccess -o bind
Now, edit the .htaccess file accordingly. I just pasted the contents @szaimen posted above in #412 (comment)
Restart apache inside the snap so the changes take effect:
sudo snap restart nextcloud.apache

To enable the mount point automatically, add the following to your /etc/fstab file:
/var/snap/nextcloud/current/nextcloud/config/.htaccess /snap/nextcloud/current/htdocs/.htaccess none auto,bind,x-systemd.before=snap.nextcloud.apache.service,x-systemd.requires-mounts-for=/snap/nextcloud/current/,x-systemd.required-by=snap.nextcloud.apache.service 0 0
Then either reboot, or execute:
sudo systemctl daemon-reload; sudo systemctl restart local-fs.target

Note, this does rely on symlinks (/snap/nextcloud/current). Systemd mounting doesn't work with symlinks, but that's fine here, since the link itself wouldn't change unless there was an update. The symlink is parsed only during evaluation (daemon-reload or reboot).
The result is a generated unit named snap-nextcloud-28549-htdocs-.htaccess.mount (for revision 28549 of nextcloud). Assuming an update to the snap recreates the service unit files, then that mount unit should update accordingly.

Gotchas:

• Since I know nothing about snaps, I'm not sure if this bind mount can be done before it starts. Someone with more knowledge might know. Ideally it would either be placed in the host's /etc/fstab, or done during the snap startup.
  systemd.automount will not work, as the destination is a file, not a directory.

• sudo nextcloud.occ maintenance:update:htaccess still doesn't work. I don't know why. I tried a little debugging, but I didn't spend a whole lot of time on it, since I had the workaround of just pasting the contents manually.
  Does that mean the file still isn't writable inside the snap itself? If that's true, then perhaps security isn't an issue.

• Security? I'm not 100% positive on the security ramifications of this, but if the file still isn't writable inside the snap, then perhaps there isn't a concern.

• Updates - I don't know what will happen when the snap updates. Presumably your custom .htaccess file will still replace the original. However, you need to check to make sure the contents haven't changed separately from what you added.

EDIT: On a side note... snaps seems like a really bad design. I feel like I shouldn't be allowed to do that.

[michielbdejong]

@Gwindalmir Great, thanks for the pointer to using bind mounts for this! For me your exact instructions didn't work; I was about to mount my editable .htaccess as for instance /snap/nextcloud/current/htdocs/robots.txt but when trying to mount it to /snap/nextcloud/current/htdocs/.htaccess it inexplicably said mount: /snap/nextcloud/28586/htdocs/.htaccess: mount(2) system call failed: No such file or directory.. I did get it working though, by simply bind-mounting the whole /snap/nextcloud/current/htdocs/ directory from an editable location. Thanks!

[github-actions]

This issue is stale because it has been without activity for 60 days. It will be closed after 7 more days of inactivity.

[Fuseteam]

Uh i thought there was a PoC

[lampgnu]

Hello,

I'm interested, but I'havn't understanding the solution.

It is possible help me?

Thanks you.

[github-actions]

This issue is stale because it has been without activity for 60 days. It will be closed after 7 more days of inactivity.

[martindale]

Interested in progress here... looks like some change in Nginx routing may do it?

[Fuseteam]

not sure, but i also think it would be nice 🤔

[yukeiyang]

Seems this issue still not be solved. I really like Pretty URL. But anyway, Thank you guys for your wonderful jobs in this field, and I run this version very well, and Cool.

[Polve]

Hello, a lot of time passed and I wonder if in the meantime a solution for this problem has been found?

[justinhartman]

I managed to figure it out, without mounting the snap read/write.

What I did was copy the .htaccess file from inside the snap, to the config directory, then used a bind mount to overlay the copy on top of the original, then restarted apache.

Here's the steps:
#412 (comment)

@Gwindalmir This worked out the box for me as per your instructions on Nextcloud v24. One question, have you managed to update the navigation in Nextcloud perhaps? All my links still reference index.php but are accessible with or without it in the URL.

[Gwindalmir]

I managed to figure it out, without mounting the snap read/write.

What I did was copy the .htaccess file from inside the snap, to the config directory, then used a bind mount to overlay the copy on top of the original, then restarted apache.

Here's the steps:
#412 (comment)

@Gwindalmir This worked out the box for me as per your instructions on Nextcloud v24. One question, have you managed to update the navigation in Nextcloud perhaps? All my links still reference index.php but are accessible with or without it in the URL.

I didn't even notice the links still have index.php in them, at least the file links themselves do. App and other links don't.

Note, I don't use the snap anymore. I moved the installation to a new system using docker instead. I have far more control now.

[KwisatzJim]

I just installed the snap version of NextCloud and tried @Gwindalmir steps and it worked for me. This is my first time working with snaps and it's taken some getting used to. I really like NextCloud so far!

[inithinx]

been a long time! +1

[KwisatzJim]

noticed today that I'm getting the below error and wondering if it's due to performing the steps given by @Gwindalmir

Some files have not passed the integrity check. Further information on how to resolve this issue can be found in the documentation ↗. (List of invalid files… / Rescan…)

and clicking on List of invalid files gives the following

Technical information
=====================
The following list covers which files have failed the integrity check. Please read
the previous linked documentation to learn more about the errors and how to fix
them.

Results
=======
- core
	- INVALID_HASH
		- .htaccess

Raw output
==========
Array
(
    [core] => Array
        (
            [INVALID_HASH] => Array
                (
                    [.htaccess] => Array
                        (
                            [expected] => e1ce1c04d22356f6760bf5499347db365d48c0d6e7e3f085d8b80581f85d766c1e8b5862ff639ce9a40e2aef5c60dbee2386bf506e572453c5a1a5c3413e38e3
                            [current] => 538fa968b08fb7fd33a2973908930ed76d0d0460a1c7576a0cca958c6ea3b5d4a76dd1c6a0bc82d799b0623ff6436de1d4badab6c48d3cdafb98c7075d9548ad
                        )

                )

        )

)

[asheroto]

@nextcloud-snap @kyrofa this issue has been open for 7 years.

I see that @szaimen worked on this awhile back with #1794 but was unable to finish due to technical reasons.

As an easy workaround, would you consider supporting the solution by @Gwindalmir with a simple command such as...

nextcloud.enable-pretty-urls

It could run a small script that implements the solution above, nothing major.

😊

[kyrofa]

As an easy workaround, would you consider supporting #412 (comment) by @Gwindalmir with a simple command such as...

I'm afraid not, for two reasons:

1. It's a dangerous hack that will break in all sorts of scenarios (including upgrades)
2. The snap doesn't actually have the privileges necessary to pull off bind mounts on the host

[asheroto]

Understood. Maybe the ticket should close?

Hopefully nextcloud will consider enabling this by default or provide a method to handle this without using .htaccess. I've had pretty URLs on my nextcloud installation for years without any issues. It's simply handled by Apache.

Thanks for the info.

[kyrofa]

No need to close it, I still think this is possible to pull off, it's just not high on the list of priorities for the maintainers. Contributions always welcome!