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

{J,CS}SResourceLocator: account for symlinks in app path #7061

Merged
merged 4 commits into from
Nov 14, 2017

Conversation

kyrofa
Copy link
Member

@kyrofa kyrofa commented Nov 4, 2017

Currently, if the app path includes a symlink, the calculated webDir will be incorrect when generating CSS and URLs will be pointing to the wrong place, breaking CSS.

This PR fixes #6028 by using realpath when retrieving app path, which makes these issues go away.

Currently, if the app path includes a symlink, the calculated webDir
will be incorrect when generating CSS and URLs will be pointing to the
wrong place, breaking CSS.

Use realpath when retrieving app path, and these issues go away.

Fix nextcloud#6028

Signed-off-by: Kyle Fazzari <kyrofa@ubuntu.com>
@kyrofa kyrofa force-pushed the bugfix/6028/app_path_realpath branch from 8a2a077 to b0d2966 Compare November 4, 2017 06:53
@kyrofa
Copy link
Member Author

kyrofa commented Nov 4, 2017

I'd love to cover this in a test if anyone can point me in the right direction.

@codecov
Copy link

codecov bot commented Nov 4, 2017

Codecov Report

Merging #7061 into master will increase coverage by 0.02%.
The diff coverage is 50%.

@@             Coverage Diff              @@
##             master    #7061      +/-   ##
============================================
+ Coverage     50.73%   50.76%   +0.02%     
  Complexity    24412    24412              
============================================
  Files          1579     1579              
  Lines         93321    93323       +2     
  Branches       1359     1359              
============================================
+ Hits          47348    47375      +27     
+ Misses        45973    45948      -25
Impacted Files Coverage Δ Complexity Δ
lib/private/Template/CSSResourceLocator.php 0% <0%> (ø) 26 <0> (ø) ⬇️
lib/private/Template/JSResourceLocator.php 50% <100%> (+50%) 22 <0> (ø) ⬇️
apps/files_trashbin/lib/Trashbin.php 72.28% <0%> (-0.25%) 136% <0%> (ø)
lib/private/Template/ResourceLocator.php 69.35% <0%> (+1.61%) 25% <0%> (ø) ⬇️

@MorrisJobke
Copy link
Member

I'd love to cover this in a test if anyone can point me in the right direction.

cc @skjnldsv @juliushaertl

@MorrisJobke
Copy link
Member

I guess we need the same for the JSCombiner?

@MorrisJobke MorrisJobke added the 3. to review Waiting for reviews label Nov 7, 2017
@skjnldsv
Copy link
Member

skjnldsv commented Nov 7, 2017

Is this related to #5289?

@juliushaertl
Copy link
Member

I'd love to cover this in a test if anyone can point me in the right direction.

I guess you could write a unit test for that with creating a symlink using http://php.net/manual/en/function.symlink.php. It seems that the CSSResourceLocator class is not unit-tested at all: https://github.com/nextcloud/server/tree/master/tests/lib/Template

@MorrisJobke MorrisJobke added 2. developing Work in progress and removed 3. to review Waiting for reviews labels Nov 7, 2017
@kyrofa
Copy link
Member Author

kyrofa commented Nov 7, 2017

Is this related to #5289?

I'm not sure. It's certainly possible.

@kyrofa
Copy link
Member Author

kyrofa commented Nov 7, 2017

@MorrisJobke I'm assuming you're talking about the JSResourceLocator? Assuming so, I've pushed that change here as well.

@juliushaertl I've also pushed tests for both JSResourceLocator as well as CSSResourceLocator that cover the functionality introduced here. I assume they're run automatically in CI, right? Or do I need to alter another file somewhere?

Signed-off-by: Kyle Fazzari <kyrofa@ubuntu.com>
@kyrofa kyrofa force-pushed the bugfix/6028/app_path_realpath branch from 8e3e053 to 06ba1a8 Compare November 7, 2017 22:54
@MorrisJobke
Copy link
Member

@juliushaertl I've also pushed tests for both JSResourceLocator as well as CSSResourceLocator that cover the functionality introduced here. I assume they're run automatically in CI, right? Or do I need to alter another file somewhere?

They run automatically (if they are located in a tests/ folder), but cause a Fatal error:

PHP Fatal error:  Cannot redeclare Test\Template\randomString() (previously declared in /drone/src/github.com/nextcloud/server/tests/lib/Template/CSSResourceLocatorTest.php:47) in /drone/src/github.com/nextcloud/server/tests/lib/Template/JSResourceLocatorTest.php on line 46

This seems to be the only way to have the same helpers used between
tests in a manner that works for both standalone phpunit and
autotest.sh.

Signed-off-by: Kyle Fazzari <kyrofa@ubuntu.com>
@kyrofa kyrofa force-pushed the bugfix/6028/app_path_realpath branch from 5a69f9b to 9c24b7b Compare November 8, 2017 20:45
@kyrofa
Copy link
Member Author

kyrofa commented Nov 8, 2017

They run automatically (if they are located in a tests/ folder), but cause a Fatal error:

Thanks @MorrisJobke, all fixed up and ready for review.

@kyrofa kyrofa added 3. to review Waiting for reviews and removed 2. developing Work in progress labels Nov 8, 2017
@MorrisJobke MorrisJobke added this to the Nextcloud 13 milestone Nov 8, 2017
@kyrofa kyrofa changed the title CSSResourceLocator: account for symlinks in app path {J,CS}SResourceLocator: account for symlinks in app path Nov 8, 2017
@juliushaertl
Copy link
Member

@kyrofa Do you have some steps to reproduce the issue/test the pr? Symlinking the apps folder doesn't cause the issue on my setup.

@kyrofa
Copy link
Member Author

kyrofa commented Nov 9, 2017

Sure thing @juliushaertl. Note that while the fix is done in the ResourceLocators, the bug doesn't bite until CSS is generated (which is then cached). The problem isn't quite as simple as "app paths with symlinks don't work", the app path in question actually needs to be within a webroot that is a symlink, so let's use the default apps as an example.

  1. Get a completely clean, not-installed Nextcloud
  2. The webroot needs to be a symlink, so instead of /var/www/nextcloud, put Nextcloud in /var/www/actual-nextcloud.
  3. Now create /var/www/nextcloud as a symlink pointing to /var/www/actual-nextcloud (webserver should be pointing to the symlink).
  4. Before installing, add an apps_paths item pointing to the default apps, but use the symlink path for it, not the real one, e.g.:
<?php
$CONFIG = array (
  'instanceid' => 'oc4ugkbj34v5',
  'apps_paths' => array(
        array(
                # Note the use of nextcloud instead of actual-nextcloud
                'path'=> '/var/www/nextcloud/apps',
                'url' => '/apps',
                'writable' => true,
        ),
  ),
);

Now you've set things up such that:

  1. The CSS has not yet been generated since Nextcloud is not installed
  2. The webroot, which is a symlink, will be resolved into /var/www/actual-nextcloud
  3. The app path uses the symlink, but in master, doesn't get resolved (that's what this PR fixes)
  4. When the CSS is generated, that webroot will be used to rewrite URLs for the apps, but the app path will still be /var/www/nextcloud/apps/foo and the rewrite will go sideways, creating invalid URLs to assets, thus bad CSS.

Go ahead and install Nextcloud now, and you'll see things like this:

image

// Account for the possibility of having symlinks in app path. Doing
// this in a separate variable, because an empty argument to realpath
// gets turned into cwd, which makes it hard to see if app_path got set.
$real_app_path = realpath($app_path);
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Shouldn't we also do this after the check if the app_path is empty like it is done in in the CSSResourceLocator? Otherwise $real_app_path still might be the working directory for empty app paths.

Copy link
Member Author

@kyrofa kyrofa Nov 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah the diff is hiding that from you, expand is a little below this. It's done here. I believe it's done after looking for l10n because those should be able to not exist without raising errors.

Copy link
Member Author

@kyrofa kyrofa Nov 12, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Although this will cause weird behavior with using the cwd for l10n, huh. I refactored it just a tad to account for that, and pushed it up. It means we need to check twice, but I don't see a straight-forward way around that.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Can't you just move the check got app_path and app_url in front of the realpath call? That way we don't append any js sources at cwd.

Copy link
Member Author

@kyrofa kyrofa Nov 13, 2017

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, but not without changing the l10n behavior. I don't claim to be an expert in the code, of course, but right now it seems that if a l10n file doesn't exist, the error is ignored. If we move the check above that logic, we start raising an error instead. Are we wanting that change?

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ah, ok, makes sense to keep it like this i guess. 👍

Copy link
Member

@juliushaertl juliushaertl left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Thanks @kyrofa I could reproduce it and your fix works great for that.

Signed-off-by: Kyle Fazzari <kyrofa@ubuntu.com>
@MorrisJobke
Copy link
Member

The failed unit test is unrelated.

@MorrisJobke MorrisJobke merged commit ab0a3fb into nextcloud:master Nov 14, 2017
@kyrofa
Copy link
Member Author

kyrofa commented Nov 14, 2017

Can we get this back into stable12 as well? It's the last remaining issue for the snap.

@MorrisJobke
Copy link
Member

Can we get this back into stable12 as well? It's the last remaining issue for the snap.

Could you open a backport to the stable12 branch as PR?

@kyrofa
Copy link
Member Author

kyrofa commented Nov 14, 2017

Could you open a backport to the stable12 branch as PR?

Sure thing! #7170

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

Successfully merging this pull request may close these issues.

Missing icons in Files app after 12.0.1 upgrade
4 participants