Uh oh!
There was an error while loading. Please reload this page.
{J,CS}SResourceLocator: account for symlinks in app path - #7061
Conversation
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. Fixnextcloud#6028 Signed-off-by: Kyle Fazzari <kyrofa@ubuntu.com>
8a2a077 to
b0d2966Comparekyrofa
commented
Nov 4, 2017
I'd love to cover this in a test if anyone can point me in the right direction. |
Codecov Report
@@ 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
|
MorrisJobke
commented
Nov 7, 2017
|
MorrisJobke
commented
Nov 7, 2017
I guess we need the same for the JSCombiner? |
skjnldsv
commented
Nov 7, 2017
Is this related to #5289? |
juliusknorr
commented
Nov 7, 2017
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 |
kyrofa
commented
Nov 7, 2017
I'm not sure. It's certainly possible. |
@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>
8e3e053 to
06ba1a8CompareMorrisJobke
commented
Nov 8, 2017
They run automatically (if they are located in a tests/ folder), but cause a Fatal error: |
ab14ffd to
5a69f9bCompareThis 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>
5a69f9b to
9c24b7bComparekyrofa
commented
Nov 8, 2017
Thanks @MorrisJobke, all fixed up and ready for review. |
juliusknorr
commented
Nov 9, 2017
@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. |
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.
Now you've set things up such that:
Go ahead and install Nextcloud now, and you'll see things like this: |
| // 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); |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
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?
There was a problem hiding this comment.
Ah, ok, makes sense to keep it like this i guess. 👍
juliusknorr
left a comment
There was a problem hiding this comment.
Thanks @kyrofa I could reproduce it and your fix works great for that.
Signed-off-by: Kyle Fazzari <kyrofa@ubuntu.com>
MorrisJobke
commented
Nov 13, 2017
The failed unit test is unrelated. |
kyrofa
commented
Nov 14, 2017
Can we get this back into stable12 as well? It's the last remaining issue for the snap. |
MorrisJobke
commented
Nov 14, 2017
Could you open a backport to the stable12 branch as PR? |
kyrofa
commented
Nov 14, 2017
Sure thing! #7170 |

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.