Url signature expired как исправить

4 ответа

Лучший ответ

Missing images in Instagram bridge: URL signature expired #960

Comments

lorenzos commented Dec 11, 2018 •

Searching online I came across a couple of useful links:

Looks like Instagram generates tokens for image URLs that are invalidated after some time, I can’t tell exactly how much time. Unfortunately I don’t see an immediate solution to this, I hope the discussion will make something pop up.

The only idea I have is to use an image URL that points to RSS-Bridge itself, with a params to identify the Instagram post, so it can always retrieve the imagine dynamically, with an always updated signature/token. But I don’t know if this is compatible with the current RSS-Bridge architecture.

The text was updated successfully, but these errors were encountered:

LogMANOriginal commented Dec 12, 2018

Depending on your feed reader, maybe you can enable image caching for your feed?

The only idea I have is to use an image URL that points to RSS-Bridge itself, with a params to identify the Instagram post, so it can always retrieve the imagine dynamically, with an always updated signature/token.

That might work, but such a solution is too specific to be added as feature to RSS-Bridge in my opinion. That being said, RSS-Bridge could cache images and replace URIs in feeds to use cached versions. Of course, this option needs to be optional and disabled by default. Maybe even customizable to specific bridges.

Источник

For FB profiles: «URL signature expired» 403 error #95

Comments

jalajc commented Jan 19, 2017

For few (non-recent) of existing logged in users (including me), I am reported off an error in loading the profile image thumbnail if the linked profile picture is url on �facebook.

In further probe, I found (unofficial) explanation that for security reasons, publicly accessible profile urls do expire. And therefore public profile url needs to be updated in records periodically (even if profile pic is not updated) through fb graph api access.

The text was updated successfully, but these errors were encountered:

cjvilla2012 commented Feb 12, 2017 •

I confirm this same problem with firebase-auth 10.0.1 for Android. If you have an existing Facebook authentication that has not been used in some time, a new sign in can return an expired URL in FirebaseUser.getPhotoUrl. There should be a method that can be called on FirebaseUser to force photo URL refresh.

bojeil-google commented Feb 13, 2017

You can use the underlying Firebase auth updateProfile to update the photoURL. I also believe if you sign in again via firebaseui Facebook sign in, the Facebook photo URL in providerData may get updated. When that happens, you can copy that providerData photo URL and set it to the currentUser photoURL via updateProfile.

decebal commented Nov 22, 2017

nicolasgarnier commented Aug 30, 2018

The facebook URL tat we saved on users used to expire. This has now been fixed for all new users (we construct a URL that never expires). If you have existing users that were created before the fix is in place you can implement a one-time fix to fixup your users profile URL using their Facebook UID.

Basically you need to update the profile URL to something of the form https://graph.facebook.com/$/picture?type=large

Details and code sample on how to do that can be found on this thread: googlearchive/friendlypix-web#21

Источник

Instagram/feed API media URL shows ‘URL signature expired’

I am using Instagram feed API to show my Instagram posts on my Website. But some video URL shows ‘URL signature expired‘.

3 Answers 3

You could use the media URL with some extra parameters as a solution to get the desired image instead of using the direct image link.

Notice the addon /media/?size=m

Letters could be t, m or l for different picture sizes

This should return you the desired image

Instagram has added URL signatures to their media URLs.

You can easily remove the URL signature using this regular expression: «vp.*/.<32>/.<8>/»

For example in PHP:

On the other hand, I don’t think that removing the URL signature is the best solution (is just a quick fix). The good one is to call again the Instagram api in order to get the new URL.

UPDATE

It seems that Instagram is currently checking the URL signature and returns a 403 «Access denied» error if the signature is not present, so now the only solution is to call the Instagram API again in order to get the new media URL.

UPDATE April 2018

Instagram has closed their «api.instagram.com/v1/media/» endpoint so now it’s currently not possible to update the posts urls.

A possible solution is to download the media and store them in your own servers (I do not recommend this solution because it violates the terms of the Instagram API so do this at your own risk).

Another solution is to call the original endpoint where you have find the medias again (but currently it’s difficult to manage the calls with the new API rate limit).

Also you can find some non-official Instagram APIs on github that could help you.

Источник

Instagram URL signature expired #114

Comments

djrees commented Aug 21, 2019

When embedding an instagram post (photo or video), the plugin works great and I can see the images pulling through. However, after a while the images stop appearing on my site and I get 403 error message. When loading the URL of the image directly, I get URL signature expired message.

If I embed the post again, the images pull through fine.

The text was updated successfully, but these errors were encountered:

craigliggins commented Oct 4, 2019

Any movement on providing a solution for this?

pvldigital commented Oct 15, 2019 •

Seems to be related to the changes Instagram has made. Re-adding the post will generate a new signature but it’s not a good long term solution (since the signature will expire and you’ll have to add it again).

If it’s only 1 image, you could try using the url with the size parameter e.g https://www.instagram.com/p/B3kwCXrA8xt/media/?size=l when templating. It should generate the image with the correct signature.

I’ll look into implementing a function that’ll allow embedded assets to regenerate the file instead of re-adding it.

PS: if possible, can you attach the problem json file.

23d1 commented Nov 1, 2019 •

Here’s an example json file.
example.json.zip

My current workaround is as follows;

pvldigital commented Nov 7, 2019 •

@23d1 thanks for the file!

I’m currently implementing a replace button specifically for embedded assets which should make it easier to reupload the file.

After that’s done i’ll have a more in depth look on how to automatically regenerate instagram files if it’s expired.

langlers commented Jan 8, 2020

Facing this issue as well. Looking forward to your solution. If I can help test or provide additional data, let me know.

pvldigital commented Jan 14, 2020

If the date difference is more than 13 days and if the image doesn’t return 200 then it’ll automatically replace the file with a new one that has an updated signature.

It’s not ready for release as I’m currently testing but I’ll keep you all updated.

jasonwoodland commented Feb 12, 2020

We released a fix for this issue. Feel free to reopen this if you have any more problems.

pushp1997 commented Nov 2, 2021 •

Источник

Signature mismatch when using S3 signed URLs

I have a bucket in S3 that I linked up to a CNAME alias. Let’s assume for now that the domain is media.mycompany.com. In the bucket are image files that are all set to private. Yet they are publicly used on my website using URL signing. A signed URL may look like this:

This works fine as it is. I’m using a S3 helper library in PHP to generate such URLs. Here’s the identifier of that library:

I know that it is old, but I’m relying on a lot of methods in this library, so it’s not trivial to upgrade, and as said, it works well for me. Here’s the relevant method in this library:

In my normal, working setup, I’d call this method like this:

This returns the correctly signed URL as shared earlier in this post, and all is good.

However, I’d now like to generate HTTPS URLs, and this is where I’m running into issues. Simply adding HTTPs to the current URL (by setting the last param of the method to true) will not work, it will generate a URL like this:

This will obviously not work, since my SSL certificate (which is created from letsencrypt) is not installed on Amazon’s domain, and as far as I know, there’s no way to do so.

I’ve learned of an alternative URL format to access the bucket over SSL:

This apparently works for some people, but not for me, from what I know, it’s due to having a dot (.) character in my bucket name. I cannot change the bucket name, it would have large consequences in my setup.

Finally, there’s this format:

And here I am getting very close. If I take a working non-secure URL, and edit the URL to take on this format, it works. The image is shown.

Now I’d like to have it working in the automated way, from the signing method I showed earlier. I’m calling it like this:

The change here is the alternative bucket name format, and the last parameter being set to true, indicating HTTPs. This leads to an output like this:

As you can see, it has the same format as the URL I manually crafted to work. But unfortunately, I’m getting signature errors:

I’m stuck figuring out why these signatures are incorrect. I tried setting the 4th parameter of the signing method to true and false, but it makes no difference.

Edit

Based on Michael’s answer below I tried to do the simple string replace after the call to the S3 library, which works. Quick and dirty code:

2 Answers 2

The change here is the alternative bucket name format

Almost. This library doesn’t quite appear to have what you need in order to do what you are trying to do.

That, or you need to rewrite the code in the supporting library to handle this case with another option for path-style URLs.

It’s also possible to pass-through signed S3 URLs with special configuration of CloudFront (configure the bucket as a custom origin, not an S3 origin, and forward the query string to the origin) but this defeats all caching in CloudFront, so it’s a little bit counterproductive. but it would work.

Источник