advanced-cropper / vue-advanced-cropper

The advanced vue cropper library that gives you opportunity to create your own croppers suited for any website design
https://advanced-cropper.github.io/vue-advanced-cropper/
Other
991 stars 135 forks source link

Persistant CORs error while using cropper #44

Closed rhysstubbs closed 3 years ago

rhysstubbs commented 4 years ago

I have a web app fetching images cross-origin. The server that is serving those images is configured to allow cross-origin requests and I can see the images in various places. However, when I try and load that image using the cropper I suddenly get failed CORs requests.

In the source I can see you're checking if the image src URL is cross origin, and if so then setting the anonymous flag for the canvas so it isn't in "taint" mode. Before I jump any further into the source looking for the problem, is this expected/a known issue?

Norserium commented 4 years ago

Hello, @rhysstubbs!

Please provide the response headers. If you have got no 'Access-Control-Allow-Origin' in the image loading response header, you can't get the access to content of the canvas (it will be tainted).

rhysstubbs commented 4 years ago

@Norserium, Hi!

Sorry I should have updated the issue/added a comment. So after writing that I tested with disabling cache in my browser (Chrome) and thereafter I stopped receiving the CORs errors. The images 100% have the correct CORs related headers and loading multiple times prior to being used in the Cropper component. Was disabling the cache a coincedence or could that be the reason?

Norserium commented 4 years ago

@rhysstubbs, I should notice, that if images loaded correctly, it doesn't mean that they had correct headers. The problems will appear only if you try to work with their internal content (for example, draw at a canvas and try to convert it to a blob).

rhysstubbs commented 4 years ago

Screenshot from 2020-04-08 12-43-16

@Norserium You can see the correct headers are present.

I am able to operate on the canvas. The issue is not 100% consistent. However, yesterday when I posted the issue I had not cleared my cache, once I had, the issue disappeared. I've faced exactly the same issue on multiple occasions.

When I inspect the response of the failed request, A. it is coming from cache and B. the request/response headers are not complete. If the image cache from cache then that'd make sense, right? Still not sure why the browsers cache seems to be having an affect on it.

Norserium commented 4 years ago

@rhysstubbs, I suppose, that there might be a problem with cache. Could you provide the link to image? Perhaps without domain, it doesn't matter right now.

Norserium commented 4 years ago

@rhysstubbs, any news?

mkaliberda commented 4 years ago

@Norserium Hi, I have the same problem. In my case, I'm getting an error because the cropper send the request to HTTP instead of HTTPS image

Norserium commented 4 years ago

@mkaliberda, could you provide a part of your code? The cropper should not change the protocol.

mkaliberda commented 4 years ago

Thanks for answer Yes, sure ` <cropper v-if="imageUrl" class="avatar" :src="imageUrl" :stencilProps="{ aspectRatio: 12/12 }" @change="change"

`

It's hepen when I set Image Url fist time after component is loaded

There is the method for handle change async change(data) { if (this.imageCroppedUrl) { data.canvas.toBlob((blob) => { this.profileData.avatar = new File([blob],${this.profileData.email}_avatar.png); }, 'image/png', 1); this.imageCroppedUrl = data.canvas.toDataURL('image/png'); } },

and for addAttachment(request) { this.imageUrl = URL.createObjectURL(request.file); this.profileData.avatar = request.file; }, clearAvatar() { this.imageUrl = null; this.imageCroppedUrl = null; },

image

image

Norserium commented 4 years ago

@mkaliberda, how do you invoke addAttachment method? What is request object? What protocol do you use for the site, where cropper is used?

mkaliberda commented 4 years ago

addAttachment methods work fine The site working in https and axios has https protocol too. This error happen before when I try to set a default imageUrl, it's URL that return API And I've check it. The problem in the back-end))

image

Thank you for your time!

Norserium commented 4 years ago

@mkaliberda, you are welcome!

Norserium commented 4 years ago

@rhysstubbs, I suppose some changes in 0.16.2 can affect and solve your problem.

rhysstubbs commented 4 years ago

@Norserium Thanks, I will take a look

Norserium commented 4 years ago

@rhysstubbs, adding the cache busting leads to another problems with different services, so I rolled away that changes in 0.16.3. Please provide the link to the image to reproduce this problem and advice you actual solution.

chokies commented 4 years ago

experiencing this issue with the current version using s3 end points. My cropper had a v-if and and image is already cached.

Norserium commented 4 years ago

@chokies, could you provide additional data? The link to image? Codesandbox that illustrates your problem?

bribar commented 4 years ago

Hi @Norserium

I have the same issue loading images from Amazon s3 buckets. It loads fine not using Cropper (check screenshot, third entry is 200 response).

I have a CORS policy set for my domain in s3 bucket...

image

I tried exposing the Access-Control-Allow-Origin header but doesn't come across in request. I've tried changing AllowedHeader to this <AllowedHeader>Authorization</AllowedHeader>. I've tried clearing cache.

image

image

Nothing seems to work. Any ideas on how to include it in the response headers from AWS s3?

This seems like a really cool plugin but not useful if I can't get past this.

bribar commented 4 years ago

I found this... https://intellipaat.com/community/24967/s3-not-returning-access-control-allow-origin-headers, but I think this would be the responsibility of the plugin.

Or is there an option/parameter to accomplish this?

bribar commented 4 years ago

@rhysstubbs I see you use AmazonS3, how are you getting the headers returned? Is it because you use CloudFront?

Norserium commented 4 years ago

@bribar, I do not see 'access-control-allow-origin' header in your response. image

You can try to change the following line in your rules <AllowedOrigin>MyDomainHere</AllowedOrigin> to <AllowedOrigin>*</AllowedOrigin>.

In any case I suppose that it's not the specific problem of my library and you will encounter this problem every time when you try to process image's content through canvas.

bribar commented 4 years ago

Yeah I know...Amazon s3 doesn't return it unless you make sure that you use an Origin header with every request.

I found this... https://intellipaat.com/community/24967/s3-not-returning-access-control-allow-origin-headers, but I think this would be the responsibility of the plugin.

Or is there an option/parameter to accomplish this?

Your plugin is requesting those images through xhr correct? Does it send Origin in the request?

I'm not sure how to get the header in the response from Amazon.

rhysstubbs commented 4 years ago

@rhysstubbs I see you use AmazonS3, how are you getting the headers returned? Is it because you use CloudFront?

Funnily enough I’m still experiencing problem with this CORs issue, but I haven’t given it any attention since I originally posted this issue. I will however take a look at this tomorrow as it’d be good to fix. If I come across anything I will make sure to comment here with the details. I am using CloudFront, yes.

Norserium commented 4 years ago

@bribar, could you provide any link on image at your server?

rhysstubbs commented 4 years ago

Yeah I know...Amazon s3 doesn't return it unless you make sure that you use an Origin header with every request.

I found this... https://intellipaat.com/community/24967/s3-not-returning-access-control-allow-origin-headers, but I think this would be the responsibility of the plugin. Or is there an option/parameter to accomplish this?

Your plugin is requesting those images through xhr correct? Does it send Origin in the request?

I'm not sure how to get the header in the response from Amazon.

You are correct, Amazon does not return the CORs headers unless a Origin header is specified on the request. I am going to test this locally and perhaps put in a PR if I find a stable fix.

rhysstubbs commented 4 years ago

FYI; I've forked this repo and I am currently testing the fix I've applied. In a few days once I'm confident it's working I will submit a PR :)

chokies commented 4 years ago

actually i wasnt sure how i fixed it. its was either adding the cors policy on aws or removing the v-if that i added that hides the cropper. But playing with the hard reload/clear cache thing before sometimes fixes the issue. But then im really not sure. Also im not experiencing it anymore

bribar commented 4 years ago

Hi @chokies

If I disable cache (while dev tools open) the header error doesn't come up. If I close dev tools it will appear again on refresh. But it's still an issue for the end user, who won't be using dev tools or clearing cache every time.

Can you share your CORS policy? I have that set up too, but doesn't seem to help.

@rhysstubbs I look forward to your fix!

Norserium commented 4 years ago

@bribar, alas, I can't reproduce the error until somebody provide me the link to such images. I use the images from other domain in the documentation and don't encounter any problems.

Anyway, did you try to set checkOrientation to false?

bribar commented 4 years ago

@Norserium Interestingly enough, I went to get an image url for you and noticed it's not loading with errors now, WTH haha. I see the response headers now have the correct headers. I don't know what changed.

Maybe CORS policy updates on Amazon take a while to reflect changes? I did upload a different image, maybe CORS update didn't apply to old image that existed prior to update. I have no clue.

I'll see if it pops up again.

bribar commented 4 years ago

@Norserium It's happening with this image...

https://s3-us-west-1.amazonaws.com/yalla.resources/images/clients/random_9.jpg

checkOrientation to false removes one of the errors but the Cropper image doesn't show.

Norserium commented 4 years ago

@bribar, thanks! But I can't reproduce this error with your link right now. I've already tried in Chrome and Firefox (with enabled and disabled cache).

rhysstubbs commented 4 years ago

@Norserium It's happening with this image...

https://s3-us-west-1.amazonaws.com/yalla.resources/images/clients/random_9.jpg

checkOrientation to false removes one of the errors but the Cropper image doesn't show.

Have you read through the AWS docs Troubleshooting CORS issues? This is definitely an AWS S3 issue, you were right when you previously mentioned the Origin header needs to be specified. The cropper looks to make more than 1 request for the image, if you inspect I expect you find most are sucessful and only 1 is failing?

Here are a few SO posts that will help:

I'm not working on this at the moment so can't implement/test any potential fixes. @Norserium am I right in thinking you previously looked at cache-busting?

Norserium commented 4 years ago

@rhysstubbs, yes you are right, but I decided to drop this feature, cause the library user can do it himself by adding timestamp to src.

Alas, I can't fix this problem until I get some image, that can be used to reproduce it. Like I said, I've used much images from external resources at the documentation and don't encounter any problems.

chokies commented 4 years ago

this is my cors config on aws bucket

<?xml version="1.0" encoding="UTF-8"?>

* GET *
mcpeakdb commented 3 years ago

I can reproduce this whenever I put the tags within a v-if statement. Otherwise, the same image works. I don't think the issue is with images, but some behavior with the component when contained within a v-if block.

Norserium commented 3 years ago

@mcpeakdb could you create the codesandbox, that reproduces your problem?

mcpeakdb commented 3 years ago

@Norserium i'll do my best when i'm back at my computer tomorrow. Essentially, I had a v-if block where the comparison returns false, so the cropper is hidden on page load. When changing the data to have the comparison return true to unhide the cropper, I receive the CORS error. Removing the v-if check or changing my code to have the comparison return true on page load (showing the cropper on page load) both work, as intended.

Please stand by! 👍

mcpeakdb commented 3 years ago

Hi @Norserium, of course I can't reproduce it in the sandbox (isn't that always how this goes?). I'll see if I can try to determine if there is something special about my environment, sorry this wasn't helpful.

ali4zimi commented 3 years ago

Hi @Norserium , I am using google cloud storage (bucket) and cropper does not appear. Can you help me please. I use laravel and vue. and and this is the content of my cors.php: ` 'paths' => ['api/*'],

'allowed_methods' => ['*'],

'allowed_origins' => ['*'],

'allowed_origins_patterns' => [],

'allowed_headers' => ['*'],

'exposed_headers' => ['*'],

'max_age' => 0,

'supports_credentials' => false,`
Norserium commented 3 years ago

@alibabaazimi, what does mean "cropper does not appear"? Do you encounter any errors in the console? Could you provide the link to the image?

ali4zimi commented 3 years ago

Screen Shot 2020-11-28 at 7 57 43 AM

Norserium commented 3 years ago

@alibabaazimi, I suppose, that it's not the problem of this library. To access to the image content server should return the appropriate Access-Control-Allow-Origin header, but it doesn't return one now.

If you crop the image on your server you can set canvas prop to false and image will be loaded successful, otherwise you should configure your storage correctly (perhaps it is described in this section).

I use laravel and vue. and and this is the content of my cors.php

I suppose that you shouldn't set that settings for your site. The problem most likely on the storage side, not yours.

Norserium commented 3 years ago

I've tested the image from your website in other croppers also. Same problem.

ali4zimi commented 3 years ago

Thanks for your considering. I have found the problem and it is solved now. Google cloud has its own CORS settings for its bucket. Again thank you so much

Norserium commented 3 years ago

@alibabaazimi, you are welcome!

Norserium commented 3 years ago

I wrote the short section about CORS. I hope this would be helpful.

alexfauquette commented 3 years ago

Hi @Norserium ,

Thanks for this super library. I have a problem with CORS.

My problem

I set the canvas props to false. However, the is unable to have access to the content due to the crossorigin="anonymous".

How to reproduce

<cropper
            class="cropper"
            :src="image_url"
            @change="changeCropCoordinate"
            :canvas="false"
          />

An example of URL used : https://static.openfoodfacts.org/images/products/842/314/800/0015/nutrition_es.3.400.jpg

suggestion

If I manually remove the crossorigin="anonymous" every thing works fine. I propose to add a props useCrossOrigin such that is useCrossOrigin is false, the image does not have the attribute crossorigin.

Norserium commented 3 years ago

@alexfauquette it can be considered as a bug.

I don't see any reason to set crossorigin attribute when canvas is set to false.

I assume that the best decision is the following:

  1. I will add crossorigin prop that would accept the following values: false, true, "anonymous", "use-credentials".
  2. The default value of crossorigin will depends on canvas props. If canvas is equal to true then crossorigin is equal to true ("anonymous") and vice versa.

I cannot say when I will implement it, but I try to eliminate the crossorigin attribute when canvas is equal to false today.

alexfauquette commented 3 years ago

Thanks :)