Hacker News new | ask | show | jobs
by jstanley 2021 days ago
I'm seeing an error on the homepage:

> Warning: file_get_contents(https://vimeo.com/api/v2/video/466939644.php): failed to open stream: HTTP request failed! HTTP/1.1 403 Forbidden in /home/customer/www/cognifirm.com/public_html/wp-content/plugins/Ultimate_VC_Addons/modules/ultimate_videos.php on line 208

That the site is trying to fetch the contents of a Vimeo page at runtime is quite the code smell!

2 comments

Just from that one error message we can infer the following issues:

1. Not using the built-in WP_Http class or related helper methods (wp_remote_get) that provide headers, timeouts, useragent, auth, etc.

2. Unserialising remote, untrusted PHP objects (!) (Why does Vimeo provide/encourage this?)

3. Not handling HTTP error response codes.

4. PHP errors are not hidden from users.

> Unserialising remote, untrusted PHP objects (!) (Why does Vimeo provide/encourage this?)

I see nothing in the error message to show that this is the case, what am I missing?

Take a look at the referenced URL, you'll see the returned content is something like this

    a:1:{i:0;a:23:{s:2:"id";i:466939644;s:5:"title";s:17:"Cognifirm intro 3";s:11:"description";s:0:"";s:3:"url";s:27:"https://vimeo.com/466939644";s:11:"upload_date";s:19:"2020-10-10 16:14:03";s:15:"thumbnail_small";s:49:"https://i.vimeocdn.com/video/972928988_100x75.jpg";s:16:"thumbnail_medium";s:50:"https://i.vimeocdn.com/video/972928988_200x150.jpg";s:15:"thumbnail_large";s:46:"https://i.vimeocdn.com/video/972928988_640.jpg";s:7:"user_id";i:112487323;s:9:"user_name";s:12:"Per Damgaard";s:8:"user_url";s:31:"https://vimeo.com/user112487323";s:19:"user_portrait_small";s:55:"https://i.vimeocdn.com/portrait/defaults-blue_30x30.png";s:20:"user_portrait_medium";s:55:"https://i.vimeocdn.com/portrait/defaults-blue_75x75.png";s:19:"user_portrait_large";s:57:"https://i.vimeocdn.com/portrait/defaults-blue_100x100.png";s:18:"user_portrait_huge";s:57:"https://i.vimeocdn.com/portrait/defaults-blue_300x300.png";s:21:"stats_number_of_likes";i:0;s:21:"stats_number_of_plays";i:111;s:24:"stats_number_of_comments";i:0;s:8:"duration";i:109;s:5:"width";i:1920;s:6:"height";i:1080;s:4:"tags";s:0:"";s:13:"embed_privacy";s:8:"anywhere";}}
It's designed to be directly passed to unserialize($str) which is an incredibly dangerous thing to do with potentially unsafe input.

This is perhaps the strangest API design I've ever seen and these data could have easily been returned and parsed as JSON.

All into memory no less.
Not necessarily all. It’s possible to use PHP to stream a file to the output. It’s how things like `download.php` on some websites work.
But that's not what file_get_contents does.
Yep. I’m an idiot.