encoding Imager/Imager-X error with Social Media Preview (403 error)

[cole007]

Describe the bug

We are using Imager X with a site in conjunction with Imgix and Seomatic. The Seo Preview images are not loading and this seems to be an encoding issue due to predefined values in the Imager/Imgix config. Potentially related to Issue #987

To reproduce

Steps to reproduce the behaviour:

1. Set following in Imager/Imager-x config:

'imgixConfig' => [
        'default' => [
            'domains' => [getenv('IMGIX_DOMAIN')],
            'useHttps' => true,
            'signKey' => getenv('IMGIX_SIGN_KEY'),
            'defaultParams' => ['auto' => 'format,compress'],
            'apiKey' => getenv('IMGIX_API_KEY')
        ]
    ]

2. Check Social Media Preview for article/entry with SEO image
3. Image preview throws a 403 error - open image in a new tab (via browser console)
4. Replace format,compress with format%2Ccompress in URL and image is generated/shown fine
5. Subsequent attempts to query the SEO preview image are then fine

Expected behaviour

Preview images are generated and load fine in page or via Social Media Preview window (eg /seomatic/preview-social-media?elementId=XXXX

Screenshots

If applicable, add screenshots to help explain your problem.

Versions

• Seomatic v3.4.25
• Imager-X v3.5.5
• Craft v3.7.33

[khalwat]

Unclear to me that this is an SEOmatic issue? Shouldn't Imager X be providing URLs that are URL-encoded?

[cole007]

To confirm that this issue was resolved by updating the Imager-x config to following:

    'useForNativeTransforms' => true,
    'useForCpThumbs' => true,

[shoored]

Hello, I seem to be having strange issues related to this. Depending on where or how the SEO Image URL is outputted, the URL encoding seems to differ. Is this something Imager-X is handling of in the wrong way to SEOmatic?

[khalwat]

@shoored sounds like it, especially if it works without Imager X installed / working

[shoored]

Right, that makes sense. Although the output seems to differ from SEOmatic too. But it's difficult for me to comprehend where it's coming from so I'll raise an issue at Imager-X first. Thanks Andrew.

[cole007]

Note this comment/thread/issue: https://github.com/spacecatninja/craft-imager-x/issues/133

[shoored]

Thanks @cole007, but this does not resolve it unfortunately.

[shoored]

I have added my report to that imager-x issue. Hopefully it helps to gain some insights.

[khalwat]

related: https://github.com/spacecatninja/craft-imager-x/issues/133#issuecomment-1238613021

[itsmattsoria]

@khalwat I think this may still be an issue unrelated to Imager-X. I landed here because I have a project that is experiencing the same issue that is also using Imager-X, but taking a look around at some other projects that aren't using Imager-X, but ImageOptimize, they are also getting output from SEOMatic with , and & in the URL instead of %2C and &, causing a 403 from Imgix. For example, I have a project on Craft 3.6.4 with ImageOptimize 1.6, and another on Craft 4.3.6.1 and ImageOptimize 4.0 and both are using Imgix and getting meta image URLs output from SEOMatic that same way, causing 403s. It's easy to miss because it seems like most platforms automatically reformat the URL, so it seems to work, but if you paste that URL in directly, or share it somewhere that doesn't do that auto-reformatting then you're out of luck. In the Global SEO settings in the control panel the thumbnail displays correctly and indeed requests the Image URL with %2C and &, it's just the output that has the different formatting. This may only be an issue when using SEOMatic with Imgix, so I'm not sure if the solution can be handled as default, but if there were an option in the plugin settings on how to handle the URL encoding that would be amazing. Happy to share more context or URLs in Discord if it's helpful.

[CaitlinWeb]

@khalwat Encountered this issue as a regression after upgrading from v3.4.10 to v3.4.41 recently. We use Imager-X with imgix for transforms (useForNativeTransforms => true and we have auto=compress,format as defaultParams), and now og:image URLS are returning as 403s in our production environment. 😬

We have Secure URLs turned on in imgix, which means that all imgix URLs are signed and the querystring params cannot be changed at all. SEOmatic as of v3.4.12 is now sanitizing the og:image URL so that it does not exactly match the signed URL.

For example this is what SEOmatic is returning after sanitizing (simplified url) which results in a 403:

https://[...].imgix.net/[...]image.png?auto=compress,format&crop=focalpoint&fit=crop&fp-x=0.5&fp-y=0.5&h=630&q=90&w=1200&s=885b0a96f84cda9f2e8eadd0d1880da3

This is what Imgix expects (simplified url):

https://[...].imgix.net/[...]image.png?auto=compress%2Cformat&crop=focalpoint&fit=crop&fp-x=0.5&fp-y=0.5&h=630&q=90&w=1200&s=885b0a96f84cda9f2e8eadd0d1880da3

The difference is %2C is no longer encoded, which means the querystring is not the signed version and therefore is rejected by imgix.

When I used the imgix "Sign Image URL" tool on SEOmatic's image URL that fixed the issue. (Worth noting that it still returned the signed URL with auto= encoded as mentioned previously.) But we have a lot of images so it's only a temporary fix. ~It's not ideal but I may end up setting auto=compress for now to avoid this issue, since that won't require encoding.~

---

The reason this started happening is because UrlHelper::absoluteUrlWithProtocol, which is used to render OgImage, is now being sanitized (reference). As stated this change happened in v3.4.12. The culprit is TextHelper::sanitizeUserInput, which is using rawurldecode(). That doesn't seem like the correct sanitization function to use, since URLs should be encoded when rendering.

Would be great to fix this for v3 and v4 as it impacts both versions. Hope that helps to finally get this edge case resolved!

[khalwat]

@CaitlinWeb so it's using rawurldecode() because malicious scripts attempt to pass in encoded Twig code, and this normalizes the string to ensure that when we go about stripping tags, Twig tags, etc. it's successful.

Otherwise, they could obfuscate the Twig/JavaScript code as encoded characters, which would escape the sanitizing we're doing.

You can see some of the variants we're testing against here:

https://github.com/nystudio107/craft-seomatic/blob/develop/tests/unit/SstiUnitTest.php#L49

However, perhaps what could be done from a post-processing POV is to then re-encode the result, if the destination is a URL (as in this case)

[khalwat]

Addressed in: https://github.com/nystudio107/craft-seomatic/commit/9912a75d3fe686b343b30122e52dbe3ef90a26d0 & https://github.com/nystudio107/craft-seomatic/commit/9a722a2b40b8c48eec1380f7a84ee4ec705fd387

Craft CMS 3:

You can try it now by setting your semver in your composer.json to look like this:

    "nystudio107/craft-seomatic": "dev-develop as 3.4.50",

Then do a composer clear-cache && composer update

…..

Craft CMS 4:

You can try it now by setting your semver in your composer.json to look like this:

    "nystudio107/craft-seomatic": "dev-develop-v4 as 4.0.21",

Then do a composer clear-cache && composer update

[CaitlinWeb]

Confirming that 3.4.50 has corrected this issue! Thank you!!