I am pulling Facebook posts using facebook-graph API, now the problem is Image gets expired after few days.
I have the following URL for a single Image
Old Image URL which got expired
https://scontent-a.xx.fbcdn.net/hphotos-xfp1/v/l/t1.0-9/p180x540/14377_340369866155028_6836158858133154924_n.jpg?oh=7ed0d8818ad54fac851b036d24f5e674&oe=55579EE3
New Image working URL Is
https://scontent-sin1-1.xx.fbcdn.net/hphotos-xfa1/v/l/t1.0-9/14377_340369866155028_6836158858133154924_n.jpg?oh=2f7ad72fa36fc026ad2bdcc1b0284146&oe=55C87432
I am frustrated with this issue, what could be the solution of it?
What i came to know from other community about this issue is
"You should not store Facebook CDN URLs for long time use – they can change over time.
Either request the actual image and copy that to your server – or request the current CDN URL regularly.
(You might be tempted to try other workarounds, like extracting the actual image source URL from the CDN link, but I would advise against that – because the format of that might change at any time as well.)"
you can not store facebook Images url for a long time, it expires for security purpose, so it would be a better solution to store images in your server.
Haven't updated for a long time and don't know if this works as before
You should store the original image URL for sure, and use a 302 redirect parser to get the CDN URL, one example is https://scontent-ort2-1.xx.fbcdn.net/v/t45.1600-4/120202220_23846099766190042_1642096590788171162_n.jpg?_nc_cat=108&ccb=2&_nc_sid=2aac32&_nc_ohc=CE0J2Ao5cYkAX_JJ0Me&_nc_ht=scontent-ort2-1.xx&oh=f48cbb1bec21e685e0cbaaf6782a61a1&oe=5FE056E5 and we can just guess oe=5FE056E5 means the expiration, as 5FE056E5(hexadecimal) -> 1608537829(decimal, in UTC), if you interpret this timestamp you will find the time is about a month later, and maybe we can guess the expiration is about a month after getting the CDN URL? To another similar case, you can refer to: https://stackoverflow.com/a/27596727/4721007
Related
I have downloaded the UPS Rate API zip file and the JSON documentation uses https://wwwcie.ups.com/ship/{version}/rating{requestoption} for the POST request to get information.
Watching a youtube video from 2018 however shows a different set of documentation and a different POST URL (https://wwwcie.ups.com/rest/Rate)
I can get a response from the URL on the outdated documentation and have found a few other articles/questions that are using the older URL even recently, but all I ever get from the URL in the current documentation is an Invalid Access License Number error even though the number is correct.
Can anyone shed some light on what the difference is between these two are?
Surely one of those urls is the shipping api, the other is rate?
URLS change depending on format JSON or XML or whatever.
When I request a photo from Facebook, some urls are like this:
https://{hidden_for_privacy}79141548_n.jpg
And others are like this:
https://{hidden_for_privacy}23364315_n.jpg?oh=c566c56ca9fd7eb1ed5d8bfca4255e84&oe=544AF123&__gda__=1414682395_6d2cb778f5b2c857d1be1c781e81cdfa
The second one has a few extra GET parameters (oh, oe and __gda_ _ (space is there to prevent bold).
When these parameters exist, the image will be invalid after a few days because those values will be different (you can check this by doing a new API call to get the same photo).
What do these parameters mean and how are they linked to the maximum timeframe?
Thanks!
I know some history and its purpose.
Originally facebook image url look like this
https://{*snipped*}/XXXXXXXXXXX_b.jpg
but there are more than on size of image available so people have access to thumbnail image can simply replace suffix _b with _n
(So now it is https://{*snipped*}/XXXXXXXXXXX_n.jpg)
to access to larger version of the image (if available).
Some time later facebook implements central image system that can dynamically crop and resize image on the fly upon request.
The url provided by facebook at this point of time may look like this:
https://{*snipped*}.fbcdn.net/hprofile-xxx1/v/t1.0-1/p32x32/12345678_123412341234123_4123412341234123412_n.jpg
And when people see the url their curiosity arise.
Let's try remove some parameter from the url.
https://{*snipped*}.fbcdn.net/hprofile-xxx1/v/12345678_123412341234123_4123412341234123412_n.jpg
And what they get is the largest and most complete version of the image they can possibly get from facebook server.
This method was working for a long time.
When people see image in their email (mostly profile picture) they can get complete version of image without even log into facebook.
It was working everywhere include private profile picture.
The quick fix and cheapest solution for facebook is to sign request path with some signature algorithm.
I guess they use HMAC as the core algorithm and derive HMAC input from various source including request path.
This will ensure that the only party who can generate valid url is the one who have HMAC key. (presumably just facebook)
Now old issue is fixed you can not use it anymore but there are more than one issue that can be fixed by adding MAC.
It is invalidation of access to images.
Let say people once publish their photo (now other can have both valid request path plus signed signature from facebook) and later on they change their mind and make the photo private.
However, people with valid url and signature can still fetch the image from facebook server.
To solve this issue with super cheap resource considered that they already implements HMAC calculation.
(And to obscure the fact that facebook does not actually delete your image from their system when you delete it.)
They decided to mix value derived from timestamp into input of HMAC.
(See RFC-6238 for similar usage)
So signature refreshing from facebook is periodically required to gain access to photo.
This solved the latter issue with very cheap additional resource.
And here you have it.
Some of history and rationale behind facebook's parameters.
I'm certain that there is no official document about the time frame but it should not be difficult to do some experiment yourself considered that now you know that the value of time frame you want is fixed and predictable.
I think they are facebook image session keys and they produced by facebook on every image showing. So fb servers consider that the request for an image is allowed and known by facebook itself.
Sorry for my bad English and my shallow comment, but i think the solution of this problem may be that fetch a url for a new image session when old one expired. Or i don't know your whole system but maybe you can connect to that assign-keys-for-images mechanism of facebook directly and get all fresh links.
If I am right about those parameters' working mechanisms purposes, i think there is no second solution.
Sorry for my bad English again.
I found the answer (finally). The point is that the photos are not public. If you request a private photo through the API they add a query string so that the url is not valid anymore after some time. Therefore the photo is still somewhat "private". The feature is understandable and there is no workaround other than downloading the image to some other place.
I installed YOURLS yesterday and it's amazing. There is one little quirk I can't seem to figure out. When I create a short URL but later change the original URL (where the short URL points to) it doesn't cause your browser to redirect to the new original URL if you previously clicked on the short URL before the update.
Example:
Create a brand new short URL with the destination cnn.com
Test the short URL - it will go to cnn.com
Change the original URL on the same short URL to now point to cnet.com
Click on the same short URL again, and it still went to cnn.com
Now, if I go into incognito mode or a different browser to go to that short URL after changing it, it works fine. It's almost as if the user's browser "saves" where the initial link goes and doesn't check to see if the short URL has changed its destination.
Is there a way to always have a web browser that has previously clicked on the link to always check the orignal URL in case it has changed?
Thank you!
Dan
Simple, clear your browser cookies.
Of course the browser saves the data - that's what they're supposed to do.
You need to set the expiration times on... well, everything.
I have a page I cannot fetch the public profile image from. Why is that, and why does it happen?
The page in question is: (WARNING: NSFW-ish images of strippers, real sorry, only example I could find - no need to view the page anyway)
https://www.facebook.com/pages/Texas-Poolhouse/98758030102
I can access the page through the graph API. Notice that the results tell me the ID is 98758030102, as expected:
https://developers.facebook.com/tools/explorer/?method=GET&path=98758030102
And even get the image URL this way too:
https://developers.facebook.com/tools/explorer/?method=GET&path=98758030102%2Fpicture
However, using the ID, I cannot fetch the image the way I normally do. I just get a blue question mark:
http://graph.facebook.com/98758030102/picture
Are you sure you're using an access token from a user who can see the page? I can see the correct image when using my own access token - if you're not using an access token you're limited to the information which is publicly available and given the nature of the page it's probably limited to adults only because of its alcohol and/or stripper content.
I realize that this is an old question but I will add my answer for future searchers since this worked for me.
You say that using this as the image URL does not work. http://graph.facebook.com/98758030102/picture
Well I got curious and changed the http:// to https:// and entered my page ID in place of yours and it worked.
I am assuming by turning the connection secure it allows the graphi api to fetch the image.
This URL should work.
https://graph.facebook.com/YOUR_PAGE_ID_NUMBER/picture
Adding the access_token GET parameter to the url makes sure users who are allowed to view the page image will see it (18yo++ in this case). I have, however, not found a way to, through the API, determine when or why pages are not accessible by certain users.
I've been at this for almost 3 days straight and now I can't even think clearly anymore.
All I'm trying to do is to get my featured image thumbnail to appear when I paste the link in Facebook.
I'm using the Wordpress Facebook Open Graph protocol plugin which generates all the correct og meta properties.
My thumbnail images are 240x200px which respects the minimum requirements and also respects the 3:1 ratio
I've made sure there's no trailing slash at the end of my post URLs
When I use the Facebook Object Debugger, the only warning is in regards to my locale, but that shouldn't affect it.
Facebook appears to be pulling the right image, at least the URL is correct, but the image appears as a blank square
I've gone through pretty much every thread I could find in forums, but all the information available is about using the correct og tags, which I believe I'm already doing.
Thank you very very much for any help, I'm desperate!! :)
You can troubleshoot the OpenGraph meta tags with the Debugger https://developers.facebook.com/tools/debug - this can at least show if you're using the meta tags properly and if Facebook can 'read' the image.
I finally figured out that the root of my issue was the fact that I was using an addon domain (which is really a subdomain being redirected to the top level domain) and I read on eHow (of all places :) ) that Facebook has trouble pulling data from redirected domains.
Not sure if there was another way around it, but I simply ended up creating a seperate hosting account and everything is loading properly now.
one problem youre going to run into testing is that often the first time your page or post gets liked, fb keeps whatever img it finds in your meta tags or by searching your page. so, you'll keep changing your img meta tag and still it wont show the right pic. it's very anoying. One way to get around it is to change the slug of your post. now, it has a different url and to fb, it's a different page. The downside is you lose all the likes that go with your orig url. Not a problem with a new site.
I ended here googling another problem. Maybe this might help someone:
Please bear in mind that the facebook scraper works asynchronously and will need some time (during my tests around 10 minutes) to be able to display an image after seeing it for the first time.
For more information, here's a more thorough answer on a similar problem.
Indeed, as Andy Wibbels points out the FB debugger is a really handy tool.
I faced a similar issue with a server's og:image tag pointing to a secure subdomain which actually mirrors a CDN server,
<meta property="og:image" content="https://subdomain.pathToImage.jpg" />
<meta property="og:image_secure" content="https://subdomain.pathToImage.jpg" />
The FB debugging tool allows you to see the errors that FB encounters when trying to pull the image.
In my case the subdomain was not registered under the SSL certificate used by the HTTPS protocol. Hence FB was getting the following error,
Curl Error : SSL_CACERT SSL certificate problem: unable to get local issuer certificate