Consider upgrading Embed lirary to prevent denylisting issues about oembed HOT 21 CLOSED

Will do

from oembed.

@lenvanessen Our issue here is due to CraftCMS using this plugin in its starter blog repo, they asked to keep it inline with their min requirements. I have used the latest embed/embed and it'll amazingly better has all the new PHP features, which is GREAT, but is then hard to align with Craft teams request.

My vote here would be a breaking change and mark a new release, v2.0.0, which will align with the latest embed packages which is 7.4. Otherwise it's gonna be a requirement of the embed/embed package to strip the PHP 7.4 features to help the transition and a issue should be raise on their repo.

from oembed.

@reganlawton there is a new release of embed/embed coming for the v3.x branch that whitelists the 429 response for some extra providers, so we can just update the adapters there in the meantime if we run into issues

from oembed.

That’s the good news we all want 🙏 keep me updated and we can get that tagged up

from oembed.

@reganlawton - it looks like upstream updated, can you update your requirements? I've suddenly run into this issue.

from oembed.

Update: using 3.4.7, i get the following error when a 429 exists:

from oembed.

I should be able to account for this error @adrienne Ill set aside some time today to update the composer file

from oembed.

@reganlawton - you may also have to add an extra error-check to account for the weird serialization error there.

Ideally if i get a 429 out of oEmbed i want to use some kind of fallback image/data, so just returning false or null without triggering an exception would be good?

from oembed.

Yeah I’ve been playing with it today few edge cases I’m working on fixing. I normally just return a iframe if the URL itself as fallback but from memory I have the valid() method to check.

I’m just out at dinner atm so I can’t check.

from oembed.

@adrienne Your issue, which I stupidly got the HTTP code missed up with another HTTP code, is youtube rate limiting you. If you have a link that is hit often and your getting HTTP 429, you should look into use the cache feature in the plugin settings.

The embed/embed plugin should support the new release and will just need a composer update as I marked the requirement as "embed/embed": "^3.0" which should cover the new updates on that branch.

from oembed.

@reganlawton - Yeah, i know it's me being rate limited. But it shouldn't throw an exception like that, it should return some kind of sensible default (or at least boolean FALSE). Throwing an exception takes down the whole page.

from oembed.

I can add another catch layer in there and might be best to return something HTML based.so that it’s a visually debuggable.

from oembed.

@reganlawton - yeah, i agree. I've been thinking about this for days, bc i've got a site about to launch, and i think my ideal would be the following:

In the event of a 429,

• {{ entry.field.render }} returns a plain iframe with the stored URL
• {{ entry.field.media.url }} returns the stored URL
• {{ entry.field.media.image }} and its friends (like .images and .width and .height ) would return info about a default fallback image that can be set in settings (That way i can just have a single generic "play this video" image instead of having to set it per-item)
• Everything else returns either (a blank string or null), or possibly some sort of renderable error message that isn't an exception (and possibly this preference could also be set in settings? or you could just tie it all to debugMode, which might be even better.)

But throwing the exception is a serious nonstarter for me on this site that's about to launch and i'm possibly in the position of having to fork and do a fix. If i do i'll submit a pull request, obviously, but i'm kind of hoping you can at least get the extra error checking and returning something meaningful in before i have to pull the trigger on that.

from oembed.

Hey guys, I'm running into this 429 issue myself at the moment. I was about to open a new issue before I came across this old one. Are there any updates on the status of this? Did this ever get resolved?

Thanks!

from oembed.

@loweoj This issue was due to the oembed provider blocking the request it normally was resolved by using the latest embed/embed and I believed it was resolved. Can I ask which version your using on oembed plugin and embed/embed package

from oembed.

@reganlawton I'm using wrav/oembed 1.3.6 and according to composer show embed/embed embed/embed 3.4.9

I'm still receiving an error trying to serialize anonymous class after enabling cache from OembedService.php@135
For example following an invalid url with cache enabled (192.168.0.14:3000 is not running my machine, but useful for this example):

Exception
Serialization of 'class@anonymous' is not allowed ↵
Caused by: Embed\Exceptions\InvalidUrlException
Failed to connect to 192.168.0.14 port 3000: Connection refused
in /Users/.../vendor/embed/embed/src/Embed.php at line 144

from oembed.

What oembed service runs on 192.168.0.14:3000? Are you running a custom oembed service?

from oembed.

Yes I have a custom oembed service running on that IP locally during development. However that address has nothing to do with the issue I'm seeing, which was occurring in production on YouTube URLs only. Sorry for the confusion there!

I have been getting 429 errors from YouTube for too many requests. I hadn't realised there was caching option in the plugin, which I subsequently turned on. That's when I received the serialisation error, after enabling the cache. I was still receiving 429 from YouTube for a while after I enabled the cache and so the plugin was attempting to serialise the anonymous class (used as a default in the plugin's OEmbedService.php) to the cache which was throwing the error.

from oembed.

The issue would be that your enabling caching while your rate limited already. So its caching a rate limited response which makes this a harder situation to deal with apart from waiting till your not limited and then triggering caching.

from oembed.

Hmmm, yes I'm seeing this Next Exception: Serialization of 'class@anonymous' is not allowed in /var/www/html/vendor/yiisoft/yii2/caching/Cache.php:249 error as well.

When caching on the oembed plugin is off, the page loads and the video wont display (due to 429 response).
When caching on the oembed plugin is on, the page returns a 500 error.

If caching is on, but there is a 429 response, can it bypass the caching altogether to avoid the 500 error on the front end?

from oembed.

I believe this was sorted in other releases

from oembed.