Upgraded to Version 0.14.16 still getting Sanity check failed for source (passed

ok, that sounds weird.
Hopefully I can look at it this evening.

In the meantime, to get more info, you can manually add a little change in app/plugins/webp-express/lib/classes/SanityCheck.php.

It seems to be this function that checks the path:

    public static function pathBeginsWith($input, $beginsWith, $errorMsg = 'Path is outside allowed path')
    {
        self::path($input);
        if (!(strpos($input, $beginsWith) === 0)) {
            throw new SanityException($errorMsg);
        }
        return $input;
    }

To see what the paths that are compared are, change it to:

    public static function pathBeginsWith($input, $beginsWith, $errorMsg = 'Path is outside allowed path')
    {
        self::path($input);
        if (!(strpos($input, $beginsWith) === 0)) {
            throw new SanityException($errorMsg . 'this path:' . $input . ' does not begin with this: ' . $beginsWith);
        }
        return $input;
    }

OK, I did this, but it exposes some server directories which I obfuscated:

Sanity check failed for source (passed as absolute path on nginx): Path is outside allowed path this path:/srv/www/mysite.org/shared/uploads/2018/02/MyLogosm3.png does not begin with this: /srv/www/mysite.org/releases/20190627140646/web/

Note that this site uses Trellis (https://roots.io/trellis) which uses symlinks, which I believe may be the case/issue here.

If you want to chat privately I can show you more fo what I mean.

Ah, yes, the symlinks again. I made SanityCheck::absPathIsInDocRoot work with symlinks, but I have not made SanityCheck::pathBeginsWith work with symlinks. The solution is simple: I can switch to use absPathIsInDocRoot instead – because it was actually what needed to be done

The thing I thought sounded weird was that about it working when logged in, but not else. But this may have been how it seemed. SanityCheck::pathBeginsWith is only used in the scripts (the ones called upon the redirect – only webp-on-demand.php in your case). It is not used with Bulk Convert and test convert.

I shall provide a fix soon!

It should work now (I hope!). Try updating to 0.14.18

still getting Sanity check failed for source (passed as absolute path on nginx): Path is outside document rootthis path:/srv/www.mysite.com/shared/uploads/2018/02 does not begin with this: /srv/www/www.mysite.com/releases/20190628195921/web/ on 0.14.18

The update overwrote your changes, right? So you reapplied, right? Did you add the “this path:” . $input . ” does not begin with…” message in the absPathIsInDocRoot function or in pathBeginsWith?

just found a bug in absPathIsInDocRoot. It did not try ::pathBeginsWith, only ::pathBeginsWithSymLinksExpanded. I have released as 0.14.19. I however doubt that this is why it does not work for you.

What do you get if you realpath('/srv/www/mysite.org/releases/20190627140646/web/') ?

Could it be that the image folder actually is outside the document root of the site with WebP Express ?

realpath /srv/www/mysite.org/releases/20190627140646/web/

yields…

/www/mysite.org/releases/20190627140646/web/
/srv/www/mysite.org/releases/20190627140646/web

Sorry, I meant:
realpath(‘/srv/www.mysite.com/shared/uploads/2018/02’)

Holding for today. Hopefully I get some computer time tomorrow

in PHP echo realpath(‘/srv/www/mysite.org/shared/uploads/2018/02’);

returns:

/srv/www/mysite.org/shared/uploads/2018/02

Ok, then it is seems not to be due to symlinks, but that the setup is such that the images ARE outside the document root.

I’m thinking that an option for such setups (which I would guess are rare) could be to allow the check to be bypassed by defining a constant in wp-config.php

However, bypassing this would soften security and I don’t want to rush into implementing such a setting. So, I shall consider it after my vacation (I’ll be back end July)

If you don’t mind the softened security and want something working while I’m on vacation, you can bypass the check by editing a plugin file manually, as I described here

You could also expose a filter to add arbitrary directories to check against.

Yes, good thinking. It is much better to check against a custom directories than skipping the check entirely!

Unfortunately filters are not at my disposal in the scripts that handles the conversions triggered by the redirects because these scripts do not do a WordPress bootstrap. But the directories could be set in wp-options.php. Not sure if multiple dirs are needed?