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

Theming kills pretty URL #6271

Closed
tflidd opened this issue Aug 26, 2017 · 14 comments · Fixed by #6352
Closed

Theming kills pretty URL #6271

tflidd opened this issue Aug 26, 2017 · 14 comments · Fixed by #6352

Comments

@tflidd
Copy link
Contributor

tflidd commented Aug 26, 2017

Steps to reproduce

  1. Install NC 12 with theming app enabled (but no individual theming configured)
  2. Apply steps for pretty URLs (Update pretty URLs documentation#556) for an install in subfolder nextcloud
  3. Open webinterface.

Expected behaviour

Correct rewrite of the URL. If I disable the theming app 1.3.0, the rewrites are correct.

Actual behaviour

Some Icons in the web interface are missing, I get several 404 errors:
https://example.org/core/img/actions/more-white.svg?v=1 (not the missing nextcloud subfolder)
it applies for other *.svg?v=1 files and *.woff files

Other URLs are correctly rewritten.

Seems to be an issue on more setups: https://help.nextcloud.com/t/icons-missing-path-not-rewritten/4722/2

Server configuration

Operating system: Debian 8

Web server: Apache 2.4

Database: MySQL

PHP version: 7.0

Nextcloud version: 12.0.2

It's a pretty default straight forward setup, should be easily reproducable. My .htaccess after running the occ-command:

<IfModule mod_headers.c>
  <IfModule mod_setenvif.c>
    <IfModule mod_fcgid.c>
       SetEnvIfNoCase ^Authorization$ "(.+)" XAUTHORIZATION=$1
       RequestHeader set XAuthorization %{XAUTHORIZATION}e env=XAUTHORIZATION
    </IfModule>
    <IfModule mod_proxy_fcgi.c>
       SetEnvIfNoCase Authorization "(.+)" HTTP_AUTHORIZATION=$1
    </IfModule>
  </IfModule>

  <IfModule mod_env.c>
    # Add security and privacy related headers
    Header set X-Content-Type-Options "nosniff"
    Header set X-XSS-Protection "1; mode=block"
    Header set X-Robots-Tag "none"
    Header set X-Download-Options "noopen"
    Header set X-Permitted-Cross-Domain-Policies "none"
    SetEnv modHeadersAvailable true
  </IfModule>

  # Add cache control for static resources
  <FilesMatch "\.(css|js|svg|gif)$">
    Header set Cache-Control "max-age=15778463"
  </FilesMatch>
  
  # Let browsers cache WOFF files for a week
  <FilesMatch "\.woff$">
    Header set Cache-Control "max-age=604800"
  </FilesMatch>
</IfModule>
<IfModule mod_php5.c>
  php_value upload_max_filesize 511M
  php_value post_max_size 511M
  php_value memory_limit 512M
  php_value mbstring.func_overload 0
  php_value always_populate_raw_post_data -1
  php_value default_charset 'UTF-8'
  php_value output_buffering 0
  <IfModule mod_env.c>
    SetEnv htaccessWorking true
  </IfModule>
</IfModule>
<IfModule mod_php7.c>
  php_value upload_max_filesize 511M
  php_value post_max_size 511M
  php_value memory_limit 512M
  php_value mbstring.func_overload 0
  php_value default_charset 'UTF-8'
  php_value output_buffering 0
  <IfModule mod_env.c>
    SetEnv htaccessWorking true
  </IfModule>
</IfModule>
<IfModule mod_rewrite.c>
  RewriteEngine on
  RewriteCond %{HTTP_USER_AGENT}  DavClnt
  RewriteRule ^$         /remote.php/webdav/          [L,R=302]
  RewriteRule .* - [env=HTTP_AUTHORIZATION:%{HTTP:Authorization}]
  RewriteRule ^\.well-known/host-meta /public.php?service=host-meta [QSA,L]
  RewriteRule ^\.well-known/host-meta\.json /public.php?service=host-meta-json [QSA,L]
  RewriteRule ^\.well-known/carddav /remote.php/dav/ [R=301,L]
  RewriteRule ^\.well-known/caldav /remote.php/dav/ [R=301,L]
  RewriteRule ^remote/(.*) remote.php [QSA,L]
  RewriteRule ^(?:build|tests|config|lib|3rdparty|templates)/.* - [R=404,L]
  RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
  RewriteRule ^(?:\.|autotest|occ|issue|indie|db_|console).* - [R=404,L]
</IfModule>
<IfModule mod_mime.c>
  AddType image/svg+xml svg svgz
  AddEncoding gzip svgz
</IfModule>
<IfModule mod_dir.c>
  DirectoryIndex index.php index.html
</IfModule>
AddDefaultCharset utf-8
Options -Indexes
<IfModule pagespeed_module>
  ModPagespeed Off
</IfModule>
#### DO NOT CHANGE ANYTHING ABOVE THIS LINE ####

ErrorDocument 403 /nextcloud/core/templates/403.php
ErrorDocument 404 /nextcloud/core/templates/404.php
<IfModule mod_rewrite.c>
  Options -MultiViews
  RewriteRule ^core/js/oc.js$ index.php [PT,E=PATH_INFO:$1]
  RewriteRule ^core/preview.png$ index.php [PT,E=PATH_INFO:$1]
  RewriteCond %{REQUEST_FILENAME} !\.(css|js|svg|gif|png|html|ttf|woff|ico|jpg|jpeg)$
  RewriteCond %{REQUEST_FILENAME} !core/img/favicon.ico$
  RewriteCond %{REQUEST_FILENAME} !core/img/manifest.json$
  RewriteCond %{REQUEST_FILENAME} !/remote.php
  RewriteCond %{REQUEST_FILENAME} !/public.php
  RewriteCond %{REQUEST_FILENAME} !/cron.php
  RewriteCond %{REQUEST_FILENAME} !/core/ajax/update.php
  RewriteCond %{REQUEST_FILENAME} !/status.php
  RewriteCond %{REQUEST_FILENAME} !/ocs/v1.php
  RewriteCond %{REQUEST_FILENAME} !/ocs/v2.php
  RewriteCond %{REQUEST_FILENAME} !/robots.txt
  RewriteCond %{REQUEST_FILENAME} !/updater/
  RewriteCond %{REQUEST_FILENAME} !/ocs-provider/
  RewriteCond %{REQUEST_URI} !^/.well-known/acme-challenge/.*
  RewriteRule . index.php [PT,E=PATH_INFO:$1]
  RewriteBase /nextcloud/
  <IfModule mod_env.c>
    SetEnv front_controller_active true
    <IfModule mod_dir.c>
      DirectorySlash off
    </IfModule>
  </IfModule>
</IfModule>

and of course in the config.php:

'overwrite.cli.url' => 'https://example.org/nextcloud',
  'htaccess.RewriteBase' => '/nextcloud',
@MichaIng
Copy link
Member

MichaIng commented Aug 26, 2017

As addition: I face exactly the same issue, with same config.php and .htaccess, no actual theme configured BUT with theming app DISABLED.

  • Enabling the theming app solves the issue for me!
  • Actually I just faced this by applying the pretty URLs the first time: 'htaccess.RewriteBase' => '/nextcloud', and update .htaccess => leading to the exact .htaccess as tflidd's above. I never used theming before, so had the app disabled.
  • Adding or removing ‘overwritewebroot’ => ‘/nextcloud’, and/or ‘theme’ => ‘’, doesn't change something. Also it's not any caches fault.
  • My setup is also the same as above (okay Raspbian Stretch based on Debian 9 + MariaDB 10.1, but same PHP+Apache)
  • I am quite confused now, as for me this is a contradiction now: theming app as problem and solution 😕 .

€:
Interesting, after reverting the pretty urls (remove 'htaccess.RewriteBase' => '/nextcloud', and update .htaccess), with theming app still enabled, only the top right search and settings icons were missing. Apps and nextcloud icons were there. Browser console threw another error:

apps:1 Failed to decode downloaded font: https://domain.org/nextcloud/index.php/core/fonts/OpenSans-Semibold.woff
apps:1 OTS parsing error: invalid version tag
apps:1 Failed to decode downloaded font: https://domain.org/nextcloud/index.php/core/fonts/OpenSans-Light.woff
apps:1 OTS parsing error: invalid version tag

All caches were reset of course.
Besides: Switching pretty urls (both directions) destroys somehow the AppOrder order, also the Icons URLs stay wrong, so seem to be not updated together with pretty URL switch.

Disabling the theming app now solves everything again. Switching 'theme' => '', again has no effect.

AND BAM: There it is: Enabling pretty urls now while theming app is enabled, I face the same issue again and need do disable it, as it was for tflidd.

So: The error seem to occur on many systems, by switching pretty urls. And it depends if the theming app is enabled meanwhile or not. The solution is in both cases to switch the state of the theming app.
This turns out quite interesting 😆 .

@juliusknorr
Copy link
Member

Can you try setting the htaccess.IgnoreFrontController config to true and check if that fixes your issue?

/**
* For server setups, that don't have `mod_env` enabled or restricted (e.g. suEXEC)
* this parameter has to be set to true and will assume mod_rewrite.
*
* Please check, if `mod_rewrite` is active and functional before setting this
* parameter and you updated your .htaccess with `occ maintenance:update:htaccess`.
* Otherwise your nextcloud installation might not be reachable anymore.
* For example, try accessing resources by leaving out `index.php` in the URL.
*/
'htaccess.IgnoreFrontController' => false,

@tflidd
Copy link
Contributor Author

tflidd commented Aug 27, 2017

It's strange, I didn't touch the test setup since the bug report. Now it works without any modification. But now I have a problem if I delete all the entries in the .htaccess for pretty URL.

Before I cleared the browser cache and restarted apache. I don't even use caching on the server:

<?php
$CONFIG = array (
  'instanceid' => '***',
  'passwordsalt' => '****',
  'secret' => '****',
  'trusted_domains' => 
  array (
    0 => 'example.org',
  ),
  'datadirectory' => '/var/www/nextcloud/data',
  'overwrite.cli.url' => 'https://example.org/nextcloud',
  'htaccess.RewriteBase' => '/nextcloud',
  'dbtype' => 'mysql',
  'version' => '12.0.2.0',
  'dbname' => 'nextcloud',
  'dbhost' => 'localhost',
  'dbtableprefix' => 'oc_',
  'dbuser' => '****',
  'dbpassword' => '****',
  'logtimezone' => 'UTC',
  'installed' => true,
  'user_backends' => 
  array (
    0 => 
    array (
      'class' => 'OC_User_IMAP',
      'arguments' => 
      array (
        0 => '{mail.example.org:993/imap/ssl}',
      ),
    ),
  ),
  'updater.release.channel' => 'beta',
  'loglevel' => 0,
  'log_rotate_size' => 10485760,
  'maintenance' => false,
  'allow_user_to_change_display_name' => true,
  'theme' => '',
);

@juliusknorr
Copy link
Member

But now I have a problem if I delete all the entries in the .htaccess for pretty URL.

You should not edit the .htaccess by hand. Just change the config.php and run the occ command to rebuild the htaccess file. 😉

@MichaIng
Copy link
Member

MichaIng commented Aug 28, 2017

I enabled the theming app now also again and the problem is not there anymore: All icons are shown without error.

I removed 'htaccess.RewriteBase' => '/nextcloud', and updated the .htaccess. After that I got "Access forbidden" because opening domain.org/nextcloud still wants to open https://domain.org/nextcloud/apps/activity/ instead of https://domain.org/nextcloud/index.php/apps/activity/.
By the way I enabled AppOrder, set the activity app to first place and use 'defaultapp' => 'apporder',.
Disabling the AppOrder app, solves the access problem.

Instead the top right icons (contact search & settings) and some others (e.g. navigation in files app, but folder icons are shown) do not show up. This time browser console shows a different error then for the missing whole bunch of icons before:

/nextcloud/index.php/apps/files/?dir=/&fileid=105:1 Failed to decode downloaded font: https://domain.org/nextcloud/index.php/core/fonts/OpenSans-Semibold.woff
/nextcloud/index.php/apps/files/?dir=/&fileid=105:1 OTS parsing error: invalid version tag

Don't see the connection between this and the missing icons, but who knows 😉 .
Btw.: Between every step I do an apache restart and browser cache clean. This should remove any cache relevant in this case or do I miss something?

Now I tried 'htaccess.IgnoreFrontController' => 'true',, but this doesn't have any effect.

This issue was already faced before (I mean not the one described in OT with the svg patch errors and more icons missing, especially nextcloud icon on top left, but the one with the other icons missing) reported several times on help.nextcloud.com and the solution is also here to disable the theming app, if no theming is actually used. Same worked for me now. All icons show up, no error message at all.

Now I try to enable pretty urls again, with 'htaccess.IgnoreFrontController' => 'true', and theming app disabled:

logo-icon.svg Failed to load resource: the server responded with a status of 404 ()
more-white.svg Failed to load resource: the server responded with a status of 404 ()
search-white.svg Failed to load resource: the server responded with a status of 404 ()
close-white.svg Failed to load resource: the server responded with a status of 404 ()
contacts.svg Failed to load resource: the server responded with a status of 404 ()
settings-white.svg Failed to load resource: the server responded with a status of 404 ()
folder.svg Failed to load resource: the server responded with a status of 404 ()
recent.svg Failed to load resource: the server responded with a status of 404 ()
star.svg Failed to load resource: the server responded with a status of 404 ()
share.svg Failed to load resource: the server responded with a status of 404 ()
public.svg Failed to load resource: the server responded with a status of 404 ()
delete.svg Failed to load resource: the server responded with a status of 404 ()
settings.svg Failed to load resource: the server responded with a status of 404 ()
menu.svg Failed to load resource: the server responded with a status of 404 ()
OpenSans-Semibold.woff Failed to load resource: the server responded with a status of 404 ()
breadcrumb.svg Failed to load resource: the server responded with a status of 404 ()
close.svg Failed to load resource: the server responded with a status of 404 ()
add.svg Failed to load resource: the server responded with a status of 404 ()
triangle-s.svg Failed to load resource: the server responded with a status of 404 ()
public.svg Failed to load resource: the server responded with a status of 404 ()
star.svg Failed to load resource: the server responded with a status of 404 ()
share.svg Failed to load resource: the server responded with a status of 404 ()
more.svg Failed to load resource: the server responded with a status of 404 ()

Mouse over the SVGs show again the misleading path with missing /nextcloud.
Solution now is again to ENABLE the theming app 😆 . So once more you can see that it depends on the state of the theming app, when switching to pretty urls and that switching the theming app is again the only solution found so far.

To show my final config.php:

{
    "system": {
        "passwordsalt": "***REMOVED SENSITIVE VALUE***",
        "secret": "***REMOVED SENSITIVE VALUE***",
        "trusted_domains": [
            "localhost",
            "domain.org"
        ],
        "datadirectory": "\/mnt\/sda\/ncdata",
        "dbtype": "mysql",
        "version": "12.0.2.0",
        "memcache.local": "\\OC\\Memcache\\APCu",
        "filelocking.enabled": true,
        "memcache.locking": "\\OC\\Memcache\\Redis",
        "redis": {
            "host": "\/var\/run\/redis\/redis.sock",
            "port": 0,
            "dbindex": 0,
            "password": "***REMOVED SENSITIVE VALUE***",
            "timeout": 1.5
        },
        "dbname": "nextcloud",
        "dbhost": "localhost",
        "dbtableprefix": "oc_",
        "dbuser": "***REMOVED SENSITIVE VALUE***",
        "dbpassword": "***REMOVED SENSITIVE VALUE***",
        "installed": true,
        "instanceid": "ocv2j0skx6hk",
        "loglevel": 3,
        "logtimezone": "Europe\/Berlin",
        "trashbin_retention_obligation": "disabled",
        "versions_retention_obligation": "disabled",
        "skeletondirectory": "",
        "defaultapp": "apporder",
        "maintenance": false,
        "overwrite.cli.url": "https:\/\/domain.org\/nextcloud",
        "htaccess.IgnoreFrontController": "true",
        "htaccess.RewriteBase": "\/nextcloud",
        "mail_smtpmode": "smtp",
        "mail_smtpauthtype": "LOGIN",
        "mail_smtpsecure": "tls",
        "mail_from_address": "...",
        "mail_domain": "...",
        "mail_smtpauth": 1,
        "mail_smtphost": "mail.gmx.net",
        "mail_smtpport": "587",
        "mail_smtpname": "***REMOVED SENSITIVE VALUE***",
        "mail_smtppassword": "***REMOVED SENSITIVE VALUE***"
    }
}

I will have a look if somehow time solves the issue again 😉 .

€: Okay, just opened my nextcloud with MS Edge and there all icons show up. So in the end it indeed seems to be a browser cache problem. I just wonder which browser cache, as I clear it in between 😕 .
€€: Removing cookies and thus need to log into my nextcloud resolved the issue also for main browser now. As I remember just logout+login didn't help. Will try it again...

@juliusknorr
Copy link
Member

Now I try to enable pretty urls again, with 'htaccess.IgnoreFrontController' => 'true', and theming app disabled:

Can you use a boolean value true without the quotes? Otherwise the check will fail. 😉

@MichaIng
Copy link
Member

MichaIng commented Aug 28, 2017

Okay, sorry, set it without quotes now. First of all he wants to access pretty urls now again => Access forbidden
Btw. I removed pretty urls from config.php again and updated .htaccess, restarted apache and cleaned browser cache + my domains cookies. Before changing htaccess.IgnoreFrontController I was able to access but the missing icons were there again. Also Edge now didn't show the icons, where all its browser data is removed on every restart.

I am again confused now. Where does it come from, that I get redirected to pretty urls now, where they are clearly unset and .htaccess does not show the lines anymore and I cleaned every cache that I know about. Even for login it tries to open https://domain.org/nextcloud/login now and says:

Datei nicht gefunden
Das ausgewählte Dokument wurde auf dem Server nicht gefunden.
Sie können zur Rückkehr zu Nextcloud hier klicken.

Removing 'htaccess.IgnoreFrontController' => true, solves the problem. Is it somehow intended that this setting forces the use of pretty urls?
€: Ah this actually says it, and also the setting directly beneath RewriteBase 😉 .

  • Otherwise your nextcloud installation might not be reachable anymore.
  • For example, try accessing resources by leaving out index.php in the URL.
    */

I am just wondering why this is necessary in my case: mod_env is enabled. How to check if it is "restricted (e.g. suEXEC)"?

€: Okay switched to pretty urls again with all the procedure and 'htaccess.IgnoreFrontController' => true, and it directly work without error. I guess now that this setting should be reported as necessary (at least in some cases) for pretty urls to work well?
Enabling/Disabling theming app also does not break or change anything now.

@juliusknorr
Copy link
Member

I am again confused now. Where does it come from, that I get redirected to pretty urls now, where they are clearly unset and .htaccess does not show the lines anymore and I cleaned every cache that I know about. Even for login it tries to open https://domain.org/nextcloud/login now and says:

I guess they are somehow cached in the generated CSS files, so changing a theming value will fix that.

Okay switched to pretty urls again with all the procedure and 'htaccess.IgnoreFrontController' => true, and it directly work without error. I guess now that this setting should be reported as necessary (at least in some cases) for pretty urls to work well?
Enabling/Disabling theming app also does not break or change anything now.

Ok, that is something for https://github.com/nextcloud/documentation

@tflidd

But now I have a problem if I delete all the entries in the .htaccess for pretty URL.

I guess that is the same issue with the cached CSS files. I guess we should also drop the cache when the htaccess changes somehow.

@tflidd
Copy link
Contributor Author

tflidd commented Sep 3, 2017

I tried again by using 'htaccess.IgnoreFrontController' => true, in a fresh setup. It didn't work for me.

What works: Go to the admin page and change the background color.

@juliushaertl Can't we use the same function in this occ-command to reset the scss cache?

$this->increaseCacheBuster();

@juliusknorr
Copy link
Member

I think I've found another way. We could just make the SCSS generation also depend on the htaccess.IgnoreFrontController by adding it to the baseurl prefix at

private function prependBaseurlPrefix($cssFile) {
return md5($this->urlGenerator->getBaseUrl()) . '-' . $cssFile;
}

That way we can detect that change automatically and regenerate the CSS stuff then.

@tflidd
Copy link
Contributor Author

tflidd commented Sep 3, 2017

The thing is, for me the IgnoreFrontController should be set to false since I'm using an apache with mod_env enabled??

@juliusknorr
Copy link
Member

@tflidd In that case there is a env variable front_controller_active set, so that should also go into the SCSS file prefix:

7b8c777#diff-dc68e93a3894ea57d470448bd3fd66e3R168

@tflidd
Copy link
Contributor Author

tflidd commented Sep 3, 2017

I finally get the right scss files, either by waiting until the cache clears itself or by changing the default theme a bit.

@juliusknorr
Copy link
Member

Fix is in #6352 Please help review. 😉

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants