Closed rhysstubbs closed 3 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).
@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?
@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).
@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.
@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.
@rhysstubbs, any news?
@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
@mkaliberda, could you provide a part of your code? The cropper should not change the protocol.
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; },
@mkaliberda, how do you invoke addAttachment
method? What is request
object? What protocol do you use for the site, where cropper is used?
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))
Thank you for your time!
@mkaliberda, you are welcome!
@rhysstubbs, I suppose some changes in 0.16.2
can affect and solve your problem.
@Norserium Thanks, I will take a look
@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.
experiencing this issue with the current version using s3 end points. My cropper had a v-if and and image is already cached.
@chokies, could you provide additional data? The link to image? Codesandbox that illustrates your problem?
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...
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.
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.
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?
@rhysstubbs I see you use AmazonS3, how are you getting the headers returned? Is it because you use CloudFront?
@bribar, I do not see 'access-control-allow-origin' header in your response.
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.
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 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.
@bribar, could you provide any link on image at your server?
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.
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 :)
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
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!
@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
?
@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.
@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.
@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).
@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?
@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.
this is my cors config on aws bucket
<?xml version="1.0" encoding="UTF-8"?>
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.
@mcpeakdb could you create the codesandbox, that reproduces your problem?
@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! 👍
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.
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,`
@alibabaazimi, what does mean "cropper does not appear"? Do you encounter any errors in the console? Could you provide the link to the image?
@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.
I've tested the image from your website in other croppers also. Same problem.
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
@alibabaazimi, you are welcome!
I wrote the short section about CORS. I hope this would be helpful.
Hi @Norserium ,
Thanks for this super library. I have a problem with CORS.
I set the canvas
props to false
. However, the is unable to have access to the content due to the crossorigin="anonymous"
.
<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
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
.
@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:
crossorigin
prop that would accept the following values: false
, true
, "anonymous"
, "use-credentials"
.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.
Thanks :)
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?