403 error with plugin resources

[ner0]

Hello,

Recently I updated to the latest development version (1.7-git), which forces/defaults to using public_html folder as the root folder, this created a few issues for me, mainly because I'm on Windows, but I seem to have practically solved all the issues I had, with the exception of some 403's when RC plugins attempt to deliver resources.

A good example is newmail_notifier, where neither the desktop's notification envelope icon (mail.png) nor the sound (sound.mp3 or sound.wav) are able to be loaded. They return a 403 access denied. The main difference from all other calls is that these ones are not delivered through /public_html/static.php

Since I use Apache, I'm using .htaccess in the RC root folder to make /public_html act as the root folder by using the following:

Code Select Expand

<IfModule mod_rewrite.c>
Options +SymLinksIfOwnerMatch
RewriteEngine On
RewriteCond %{REQUEST_URI} !^public_html
RewriteRule ^(.*)$ public_html/$1 [L]
</IfModule>
This seems to work fine for 99% percent of cases, except the resources called from inside the plugins. One solution seems to be replacing 'SymLinksIfOwnerMatch' with 'FollowSymlinks', that appears to do it, but I'm unsure if that's not also downgrading the security of the folder's content.

Any suggestions are appreciated.
Thank you.

[JohnDoh]

What do you mean by latest version exactly? 1.6.10? because if so I'm not sure why you say "forces/defaults to using public_html". The reason I ask is that there are currently changes in git-master, planned for 1.7, which will make public_html the web root for security reasons but in 1.6 its only a recommendation not a requirement. I think the use of symlinks has been an issue for Windows based implementations since public_html was introduced however as part of the planned changes these will be removed.

If the fix you have found is to change "SymLinksIfOwnerMatch" to "FollowSymlinks" then check the file ownership in plugins dir (properties > security > advanced) and make sure it matches the rest of your install.

[ner0]

You're correct in your observation. I'm using the 1.7-git dev version, because I'm trying to get ahead of the changes and adjustments that I'll eventually need to make.

The plugin folder has the correct ownership, same as everything else. I believe that the problem is, in total or in part, because javascript is not subject to the rules that require server-side resources and assets to be served through /roundcubemail/public_html/static.php.

It seems I need to configure a dedicated VirtualHost... although I'm not entirely sure that this will fix this particular issue. I'll have to try.

[JohnDoh]

Then for the benefit of other users of the forum I'd like to point out that "Recently I updated to the latest version" - you are running a dev version of Roundcube, not a released version. This does not apply to version 1.6.10 that was released a few days ago.

I don't think you need any of those rewrite rules in your Apache vhost file. Set the document root to /public_html and its done.

The switch to static.php is a very recent one and quite a big one so some bumps are expected as the changes are tested. I tried the newmail_notifier plugin and it looks like its loading the assets correctly for me, I am running Apache on Linux not Windows. But your comment about the JS got me thinking, do you have minified versions of the JS, specifically app.js in your environment? 64df318 does include changes to app.js so if you had an existing minified version you will need to re-minify it.

[ner0]

Right, my original post was unclear in what was meant by the "latest version". Despite having made that clear already, I'll edit OP to reflect that accurately.

I didn't change my Apache vhosts settings, I just used those rewrites in .htaccess. Main reason being that I'm running it on a LAN and I don't want to deal with setting up a dedicated vhost and then also deal with potential DNS issues across VPNs. Static IP, that's it. And because I have other stuff running in the same webserver, I'm not changing the server's document root either.

The document root is indeed ../public_html/ but not ../public_html/roundcube/public_html/ hence the rewrite rule in .htaccess. I also figured that there was something wrong with the default Linux-based symlinks under Windows because I was getting a couple 403s with blank.tiff and blank.webp during login, I fixed those by replacing the symlinks with Windows-based symlinks instead (particularly resource ones in ../public_html/programs/).

On a Github issue I was told by Alec that during his test (although it was Nginx, and probably under Linux), he tried to mimic my Windows/Apache setup on a subfolder and he didn't get any issues or 403s for resources called by the plugin, and in fact for him the plugins' resources were relayed through static.php (as they should), which is not my case at all (at least for plugin assets: images, sounds, etc).

About app.js, if I understood you correctly, then no; I have the exact same version that is on the current master (dev) branch, never tweaked or minified it - the only issue I seem to be having is those media resources from plugins (just noticed that one plugin so far) which are 403ing by not being relayed through static.php.

In any case, at the moment I'm using +FollowSymlinks instead of +SymLinksIfOwnerMatch and that seems to work (despite still not routing through static.php). I'm not really against the change, I'm trying to adopt it before it becomes the norm.

In any case, everything seems to be working (albeit not as expected), but it works which is what's important.