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.
Related
As per the documentation, if I wish to upload only media without any metadata, the simple upload will do. And the documentation says:
So, as per the documentation, I formed the request as follows and the body of the request is binary data:
But I am not able to figure out where to set the parent directory information for the media being uploaded if the body is comprised of only media.
Do I need to submit two requests, one for metadata and one for media? For that, we are provided with the multipart upload.
Can anyone please help me with a working example of a simple upload?
The form-data section in this Postman docs page might help you with entering the file location.
I found a YouTube video on the subject too.
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
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.
There seems to be a silent fail when trying to stream tracks from an account.
Example:
API Gee console:
https://api.soundcloud.com/tracks/#####.json?consumer_key=###
Response: 200
Streamable: true
API Console Stream URL:
https://api.soundcloud.com/tracks/#####/stream?consumer_key=###
404 not found - (Blank white page no error in browser)
Track set to public and API streamable - All tracks on account, which were streaming as normal until the end of last week.
The consumer key works for tracks by other users, so it could be linked to this account directly?
For those coming here for an answer to this problem, it is a known bug when a song reports streamable: true yet results in a blank white page in browser when trying to stream. The bug is in the streamable boolean being false.
Email response from SoundCloud on this issue:
The developers have let me know that the problems you are having is
due to issues with RTMP.
Currently certain content on SoundCloud is using a secure streaming
method called RTMP.
To explain RTMP, even if a track is set to public and streamable by
the artist, if the artist is under a major label, this label can
further control those streaming permissions. So, it looks like it
should stream correctly, however it doesn't.
This particular bug that you have highlighted is more complicated than
originally thought, and as only a handful of tracks are affected we
unfortunately don't have the resources to dedicate a team entirely to
this project as of right now.
So unfortunately you'll just have to deal with/work around this issue.
I've noticed that i get blank page for stream url of tracks which are in "wav" format:
<original-format>wav</original-format>
other formats were working fine.
Not sure what track you're trying to stream. Some tracks are set by the artist to not be streamed.
You got the format for the url correct. Try this url with your own consumer key:
http://api.soundcloud.com/tracks/32476280/stream?consumer_key=[###]
After being in touch with the support team at SoundCloud, they provided the following:
The problems you are having is due to the content and rights holders.
To explain, profile admins have the ability to change settings as they
like, so if the tracks have stopped playing, it's likely that they
have disabled apps on the track or content. This means that the rights
holders, that own all of this content, have turned this setting off,
and we don't have control over it or the ability to enable it again.
They managed to get my "API permissions extended" because the rights holders own the SoundCloud account in question. It seems there was just a mistake somewhere along the way with denying streaming.
You'll need to log an issue with SoundCloud support if you have a similar problem.
So I cannot find any reason I am seeing the below behavior and if anybody has some insight it will be greatly appreciated.
Basically I am using the FB.UI from the JavaScript SDK to send a message to a user with a link. The link ends with a Guid, like http://www.domainname.com/register/33a1a0ae-e0fe-4eb6-9bf9-146d5492e3d6. This works sometimes, but occasionally fails with a generic 500 error from FB.
I have pulled out the HTTP POST request and have found a solution that I can recreate, unfortunately I cannot share the access code to allow SO users to actually run it (I replaced all sensitive parameters). Below are two identical requests that differ only in the Guid. The first succeeds every time and the second fails every time. I have numerous Guids that are doing this which makes if unreliable.
https://www.facebook.com/dialog/send?access_token=XXX&api_key=XXX&app_id=XXX&channel=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D5%23cb%3Df2cb8f5c1ca0402%26origin%3Dhttp%253A%252F%252Fwww.domainname.com%252Ff350c0fd55d5764%26domain%3Dwww.domainname.com%26relation%3Dparent.parent&channel_url=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D5%23cb%3Df11a615f3b71192%26origin%3Dhttp%253A%252F%252Fwww.domainname.com%252Ff350c0fd55d5764%26domain%3Dwww.domainname.com%26relation%3Dparent.parent&description=test&display=iframe&link=http%3A%2F%2Fwww.domainname.com%2Fregister%2F**33a1a0ae-e0fe-4eb6-9bf9-146d5492e3d6**&locale=en_US&name=test&next=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D5%23cb%3Df22e359d88321ce%26origin%3Dhttp%253A%252F%252Fwww.domainname.com%252Ff350c0fd55d5764%26domain%3Dwww.domainname.com%26relation%3Dparent%26frame%3Df33c13cd4ecc156%26result%3D%2522xxRESULTTOKENxx%2522&picture=http%3A%2F%2Fwww.domainname.com%2Fimg.gif&sdk=joey&to=XXX
https://www.facebook.com/dialog/send?access_token=XXX&api_key=XXX&app_id=XXX&channel=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D5%23cb%3Df2cb8f5c1ca0402%26origin%3Dhttp%253A%252F%252Fwww.domainname.com%252Ff350c0fd55d5764%26domain%3Dwww.domainname.com%26relation%3Dparent.parent&channel_url=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D5%23cb%3Df11a615f3b71192%26origin%3Dhttp%253A%252F%252Fwww.domainname.com%252Ff350c0fd55d5764%26domain%3Dwww.domainname.com%26relation%3Dparent.parent&description=test&display=iframe&link=http%3A%2F%2Fwww.domainname.com%2FFregister%2F**dd171262-dbcc-43c3-b9d1-e37dc53e3520**&locale=en_US&name=test&next=http%3A%2F%2Fstatic.ak.facebook.com%2Fconnect%2Fxd_arbiter.php%3Fversion%3D5%23cb%3Df22e359d88321ce%26origin%3Dhttp%253A%252F%252Fwww.domainname.com%252Ff350c0fd55d5764%26domain%3Dwww.domainname.com%26relation%3Dparent%26frame%3Df33c13cd4ecc156%26result%3D%2522xxRESULTTOKENxx%2522&picture=http%3A%2F%2Fwww.domainname.com%2Fimg.gif&sdk=joey&to=XXX
I tested both of these urls:
http://www.domainname.com/register/33a1a0ae-e0fe-4eb6-9bf9-146d5492e3d6
http://www.domainname.com/register/dd171262-dbcc-43c3-b9d1-e37dc53e3520
with the js sdk send method, and indeed the first url resulted in a 500 from facebook, while the first managed to send it.
I can't understand why the first UID triggers an error while the second does not.
The reason I kept asking for a working example of such urls is that when you share a url using facebook, they scrap that url (unless it's already in their cache) and extract meta data of that url so that a feed story can be composed.
Since the urls that I was trying are not accessible for facebook it might somehow trigger that error.
If I try this url:
http://laine.webhop.org/tresendas/register/33a1a0ae-e0fe-4eb6-9bf9-146d5492e3d6
then it works and I don't get the server error, even though it has the same UID as the first url I tried.
I suggest that you try to use urls accessible to facebook, if you still get errors for certain UIDs, then you should probably open a new bug report.