Amazon S3 CORS (क्रॉस-ओरिजिनल रिसोर्स शेयरिंग) और फ़ायरफ़ॉक्स क्रॉस-डोमेन फॉन्ट लोडिंग

134

वर्तमान वेबपेज की तुलना में फ़ायरफ़ॉक्स के साथ अलग-अलग मूल से फ़ॉन्ट लोड न करने का एक लंबा मुद्दा रहा है। आमतौर पर, यह समस्या तब उत्पन्न होती है जब CDN पर फोंट परोसे जाते हैं।

अन्य प्रश्नों में विभिन्न समाधान उठाए गए हैं:

सीएसएस @ फ़ॉन्ट-चेहरा फ़ायरफ़ॉक्स के साथ काम नहीं कर रहा है, लेकिन क्रोम और आईई के साथ काम कर रहा है

अमेज़ॅन एस 3 कॉर्स की शुरुआत के साथ, क्या फ़ायरफ़ॉक्स में फ़ॉन्ट लोडिंग मुद्दे को संबोधित करने के लिए कॉर्स का उपयोग करना एक समाधान है?

संपादित करें: S3 CORS कॉन्फ़िगरेशन का एक नमूना देखना बहुत अच्छा होगा।

edit2: मैं वास्तव में यह क्या किया समझ के बिना एक काम कर समाधान मिल गया है। अगर कोई भी विन्यास के बारे में अधिक विस्तृत स्पष्टीकरण प्रदान कर सकता है और पृष्ठभूमि जादू जो कि अमेज़ॅन की व्याख्या की व्याख्या पर होता है, तो इसकी बहुत सराहना की जाएगी, जैसा कि nififnab के साथ है जिन्होंने इसके लिए एक इनाम रखा है।

— VKen
स्रोत

148

अपडेट 10 सितंबर, 2014:

अब आपको नीचे दिए गए किसी भी क्वेरी स्ट्रिंग हैक्स को करने की आवश्यकता नहीं होगी क्योंकि क्लाउडफ्रंट अब ठीक से कोर का समर्थन करता है। Http://aws.amazon.com/blogs/aws/enhanced-cloudfront-customization/ और अधिक जानकारी के लिए यह उत्तर देखें : https://stackoverflow.com/a/25305915/308315

ठीक है, मुझे अंत में प्रलेखन में उदाहरणों से थोड़ा ट्वीक के साथ नीचे विन्यास का उपयोग करके फोंट मिला।

मेरे फोंट S3 पर होस्ट किए गए हैं, लेकिन क्लाउडफ्रंट द्वारा सामने हैं।

मुझे यकीन नहीं है कि यह क्यों काम करता है, मेरा अनुमान शायद यह है कि <AllowedMethod> GETऔर <AllowedHeader> Content-*इसकी आवश्यकता है।

अगर कोई भी अमेजन S3 CORS कॉन्फिगर के साथ दक्ष है, तो वह इस पर कुछ रोशनी डाल सकता है, इसकी बहुत प्रशंसा होगी।

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>https://mydomain.com</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>Content-*</AllowedHeader>
        <AllowedHeader>Host</AllowedHeader>
    </CORSRule>
    <CORSRule>
        <AllowedOrigin>https://*.mydomain.com</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>Content-*</AllowedHeader>
        <AllowedHeader>Host</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

संपादित करें:

कुछ डेवलपर्स Access-Control-Allow-Originहेडर को क्लाउडफ्रंट कैशिंग के मुद्दों का सामना कर रहे हैं । इस मुद्दे को नीचे दिए गए लिंक ( https://forums.aws.amazon.com/thread.jspa?threadID=114646 ) में AWS के कर्मचारियों ने संबोधित किया है , @ Jeff-Atwood द्वारा टिप्पणी की गई है।

लिंक किए गए धागे से, वर्कअराउंड के रूप में, विभिन्न डोमेन से कॉल के बीच अंतर करने के लिए क्वेरी स्ट्रिंग का उपयोग करने की सलाह दी जाती है । मैं यहाँ छोटा उदाहरण प्रस्तुत करूँगा।

curlप्रतिक्रिया हेडर की जांच करने के लिए उपयोग करना :

डोमेन ए: a.domain.com

curl -i -H "Origin: https://a.domain.com" http://hashhashhash.cloudfront.net/font.woff?https_a.domain.com

डोमेन ए से प्रतिक्रिया हेडर:

Access-Control-Allow-Origin: https://a.domain.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
X-Cache: Miss from Cloudfront

डोमेन B: b.domain.com

curl -i -H "Origin: http://b.domain.com" http://hashhashhash.cloudfront.net/font.woff?http_b.domain.com

डोमेन बी से प्रतिक्रिया हेडर:

Access-Control-Allow-Origin: http://b.domain.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
X-Cache: Miss from Cloudfront

आप देखेंगे कि Access-Control-Allow-Originविभिन्न मान वापस आ गए हैं, जो क्लाउडफ्रंट कैशिंग से अतीत में है।

— VKen
स्रोत

2

क्या आपने यहां वर्णित समस्याओं के समान अनुभव किया है - Access-Control-Allow-Originजब बाद में एक अलग उपडोमेन के माध्यम से अनुरोध किया जाता है , तो हेडर को कैश और अमान्य कर दिया जाता है?

— ओव

1

@ मुझे इस समस्या का अनुभव नहीं है क्योंकि मैं उन डोमेन को स्पष्ट रूप से सेट करता हूं जो संसाधनों का उपयोग करते हैं। मैंने आपके द्वारा पहले पोस्ट की गई लिंक को पढ़ा है। मैंने अस्पष्ट रूप से एक और सूत्र पर कुछ उत्तरों को याद करते हुए कहा कि डोमेन को स्पष्ट रूप से कहा जाना है, इसलिए कुछ प्रतिबंधों के कारण <AllowedOrigin> * </ AllowedOrigin> की अनुमति नहीं है। मुझे अब वे उत्तर पोस्ट नहीं मिल रहे हैं, यह ब्लॉग पोस्ट हो सकती है जिसे मैंने कहीं और पढ़ा है। उम्मीद है की वो मदद करदे।

— वीकेन

3

आपके पास एक ही CorSRule तत्वों के अंदर कई AllowedOrigin तत्व हो सकते हैं, इसलिए आप उन CORSRules को एक ही तत्व में संयोजित कर सकते हैं, क्योंकि उनमें अन्य तत्व समान हैं।

— बेन हल

4

@dan अगर S3 बाल्टी CloudFront द्वारा परोसी जाती है, तो ऐसा लगता है कि इसका उत्तर यह है कि इस आधिकारिक अमेज़न उत्तर में प्रलेखित डोमेन के अनुसार फॉन्ट क्वेरिस्ट्रिंग को अलग किया जाए

— Jeff Atwood

2

यह एक अत्यंत निराशाजनक मुद्दा रहा है। अच्छी खबर यह है कि S3 अब सही काम करता हुआ दिखाई देता है, इसलिए कम से कम CloudFront के माध्यम से webfonts के अलावा सब कुछ परोसना संभव है और सीधे S3 से फ़ॉन्ट फ़ाइलों की सेवा करना संभव है। अफसोस की बात है, क्वेरिस्ट्रिंग हैक हमारे आवेदन में वास्तव में व्यावहारिक रूप से अधिक महत्वपूर्ण रिफैक्टरिंग के बिना नहीं है, क्योंकि संपत्ति सभी रेल परिसंपत्ति पाइपलाइन के माध्यम से सेवा की जाती है, और अनुरोध समय पर परिसंपत्ति यूआरएल को ट्विस्ट करने का कोई सुविधाजनक तरीका नहीं है (वे सभी तैनाती के दौरान उत्पन्न होते हैं। जब संपत्तियां पूर्व निर्धारित हो)। सीएसएस में फ़ॉन्ट का URL पहले से ही S3 पर है।

— जैच लिप्टन

97

कुछ tweaking के बाद मुझे लगता है कि यह क्वेरी स्ट्रिंग हैक के बिना काम करने के लिए मिला है। यहाँ और जानकारी: http://docs.aws.amazon.com/AmazonCloudFront/latest/DeveloperGuide/RequestAndResponseBehaviorS3Origin.html#RequestS3-cors

मैं अपने पूरे सेटअप से गुजरने जा रहा हूं ताकि यह देखना आसान हो जाए कि मैंने क्या किया है, उम्मीद है कि इससे दूसरों को मदद मिलेगी।

पृष्ठभूमि की जानकारी: मैं R3 ऐप का उपयोग कर रहा हूं, जिसमें S3 पर संपत्ति डालने के लिए संपत्ति_sync मणि है। इसमें फोंट शामिल हैं।

S3 कंसोल के भीतर, मैंने अपनी बाल्टी, गुण और 'cors कॉन्फ़िगरेशन को संपादित करें' पर क्लिक किया, यहाँ: कॉर्स विन्यास बटन

Textarea के अंदर मैं कुछ इस तरह है:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>https://*.example.com</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>*</AllowedHeader>
    </CORSRule>
</CORSConfiguration>

फिर क्लाउडफ्रंट पैनल ( https://console.aws.amazon.com/cloudfront/home ) के भीतर मैंने एक वितरण बनाया, एक उत्पत्ति जोड़ी जो मेरे S3 बाल्टी की ओर इशारा करती है एक मूल जोड़ना

फिर S3 आधारित मूल I सेटअप को इंगित करने के लिए एक डिफ़ॉल्ट पथ के लिए एक व्यवहार जोड़ा। मैंने जो भी किया वह श्वेतसूची हेडर पर क्लिक किया और जोड़ा गया Origin: एक व्यवहार और श्वेतसूची हेडर जोड़ना

क्या होता है अब निम्नलिखित है, जो मेरा मानना है कि सही है:

1) जांचें कि S3 हेडर सही तरीके से सेट हो रहे हैं

curl -i -H "Origin: https://example.com" https://s3.amazonaws.com/xxxxxxxxx/assets/fonts/my-cool-font.ttf
HTTP/1.1 200 OK
x-amz-id-2: Ay63Qb5uR98ag47SRJ91+YALtc4onRu1JUJgMTU98Es/pzQ3ckmuWhzzbTgDTCt+
x-amz-request-id: F1FFE275C0FBE500
Date: Thu, 14 Aug 2014 09:39:40 GMT
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
Vary: Origin, Access-Control-Request-Headers, Access-Control-Request-Method
Cache-Control: public, must-revalidate, proxy-revalidate, max-age=180
Last-Modified: Mon, 09 Dec 2013 14:29:04 GMT
ETag: "98918ee7f339c7534c34b9f5a448c3e2"
Accept-Ranges: bytes
Content-Type: application/x-font-ttf
Content-Length: 12156
Server: AmazonS3

2) हेडर के साथ चेकफ्रंट काम करता है

curl -i -H "Origin: https://example.com" https://xxxxx.cloudfront.net/assets/fonts/my-cool-font.ttf
HTTP/1.1 200 OK
Content-Type: application/x-font-ttf
Content-Length: 12156
Connection: keep-alive
Date: Thu, 14 Aug 2014 09:35:26 GMT
Access-Control-Allow-Origin: https://example.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
Cache-Control: public, must-revalidate, proxy-revalidate, max-age=180
Last-Modified: Mon, 09 Dec 2013 14:29:04 GMT
ETag: "98918ee7f339c7534c34b9f5a448c3e2"
Accept-Ranges: bytes
Server: AmazonS3
Vary: Origin
X-Cache: Miss from cloudfront
Via: 1.1 77bdacfea247b6cbe84dffa61da5a554.cloudfront.net (CloudFront)
X-Amz-Cf-Id: cmCxaUcFf3bT48zpPw0Q-vDDza0nZoWm9-_3qY5pJBhj64iTpkgMlg==

(ध्यान दें कि ऊपर बादल से एक मिस था क्योंकि ये फाइलें 180 सेकंड के लिए कैश की जाती हैं, लेकिन वही हिट पर काम कर रही थी)

3) एक अलग मूल के साथ क्लाउडफ्रंट मारो (लेकिन एस 3 बाल्टी के लिए कोर पर अनुमति दी गई है) - Access-Control-Allow-Originकैश नहीं है! वाह!

curl -i -H "Origin: https://www2.example.com" https://xxxxx.cloudfront.net/assets/fonts/my-cool-font.ttf
HTTP/1.1 200 OK
Content-Type: application/x-font-ttf
Content-Length: 12156
Connection: keep-alive
Date: Thu, 14 Aug 2014 10:02:33 GMT
Access-Control-Allow-Origin: https://www2.example.com
Access-Control-Allow-Methods: GET
Access-Control-Max-Age: 3000
Access-Control-Allow-Credentials: true
Cache-Control: public, must-revalidate, proxy-revalidate, max-age=180
Last-Modified: Mon, 09 Dec 2013 14:29:04 GMT
ETag: "98918ee7f339c7534c34b9f5a448c3e2"
Accept-Ranges: bytes
Server: AmazonS3
Vary: Origin
X-Cache: Miss from cloudfront
Via: 1.1 ba7014bad8e9bf2ed075d09443dcc4f1.cloudfront.net (CloudFront)
X-Amz-Cf-Id: vy-UccJ094cjdbdT0tcKuil22XYwWdIECdBZ_5hqoTjr0tNH80NQPg==

ऊपर नोट करें कि क्वेरी स्ट्रिंग हैक के बिना डोमेन सफलतापूर्वक बदल गया है।

जब मैं ओरिजिन हेडर को बदलता हूं, X-Cache: Miss from cloudfrontतो पहले अनुरोध पर हमेशा ऐसा लगता है कि बाद में मुझे उम्मीद हैX-Cache: Hit from cloudfront

पुनश्च यह ध्यान देने योग्य है कि कर्ल-आई (पूंजी I) करते समय एक्सेस-कंट्रोल-अनुमति-मूल हेडर नहीं दिखाएगा क्योंकि यह केवल एक हेड है, मैं इसे जीईटी बनाने और स्क्रॉल करने के लिए करता हूं।

— एमानो गाहन
स्रोत

काम किया जब अन्य सभी नहीं किया। ऐसे विस्तार से पोस्ट करने के लिए समय निकालने के लिए धन्यवाद!

— १२

यह काम करता हैं!! FYI करें - इसका परीक्षण करते समय मेरे पास एक बहुत बड़ा http प्रतिक्रिया पाठ था ... इस कर्ल समाधान का उपयोग करने के लिए उत्तर को संपादित करने वाले ... stackoverflow.com/questions/10060098/…

— माइकल गोरहम

कूल धन्यवाद दोस्तों - यह देखकर खुशी होती है कि यह दूसरों के लिए काम कर रहा है।

— इमानो घन

मैं आपको यह नहीं बता सकता कि आपने हमारी कितनी मदद की है! +1

— कुछ खास

1

Originदर्शकों से ग्राहक हेडर जोड़ने के लिए +1 ताकि क्लाउडफ़्रंट उस हेडर के आधार पर ऑब्जेक्ट को कैश करता है (और सर्वर को आगे बढ़ाकर उपयोगकर्ता को वापस भेज देता है)

— सेबस्टियन सौनिएर

13

हरोकू को अंतिम धक्का तक मेरे फोंट सही ढंग से परोसे गए ... मुझे पता नहीं क्यों, लेकिन कोर में वाइल्डकार्ड ने अनुमति दी कि मूल ने काम करना बंद कर दिया। मैंने अपने सभी प्रीप्रो और प्रो डोमेन को बाल्टी सेटिंग में CORS पॉलिसी में जोड़ दिया है, इसलिए अब यह इस तरह दिखता है:

<CORSConfiguration>
    <CORSRule>
        <AllowedOrigin>http://prepro.examle.com</AllowedOrigin>
        <AllowedOrigin>https://prepro.examle.com</AllowedOrigin>
        <AllowedOrigin>http://examle.com</AllowedOrigin>
        <AllowedOrigin>https://examle.com</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
        <AllowedHeader>Authorization</AllowedHeader>
    </CORSRule>

</CORSConfiguration>

अद्यतन: अपना http://localhost:PORTभी जोड़ें

— luigi7up
स्रोत

1

इस समाधान को साझा करने के लिए धन्यवाद। इसने मेरे लिए काम किया।

— रयान मॉन्टगोमरी

8

खैर, प्रलेखन में कहा गया है कि आप कॉन्फ़िगरेशन को "अपनी बाल्टी में cors subresource" के रूप में चिपका सकते हैं। मुझे इसका मतलब यह था कि मैं विन्यास के साथ अपनी बाल्टी की जड़ में "cors" नामक एक फ़ाइल बनाऊंगा, लेकिन यह काम नहीं करेगा। अंत में मुझे अमेज़ॅन एस 3 प्रशासन क्षेत्र में लॉगिन करना पड़ा और propertiesअपने बाल्टी के संवाद के भीतर कॉन्फ़िगरेशन को जोड़ना पड़ा ।

S3 कुछ बेहतर प्रलेखन का उपयोग कर सकता है ...

— nzifnab
स्रोत

1

हां, लेकिन मैं गुण पैनल में कुछ नए इंटरफ़ेस परिवर्तनों को प्राप्त करने के लिए भाग्यशाली था। मैं बकेट नीतियों का संपादन कर रहा हूं, इसलिए स्वाभाविक रूप से मैं एक ही पैनल में कॉर्स कॉन्फ़िगरेशन के लिए शिकार करता हूं।

— वीकेन

मेरे लिए काम किया, मैं अपने आवेदन में इसे सेट करना

— चाह रहा

7

यदि आप इसका उपयोग करते हैं तो Amazon S3 CORS कॉन्फ़िगरेशन (S3 बाल्टी / अनुमतियां / CORS) में:

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>

जावास्क्रिप्ट जावास्क्रिप्ट और सीएसएस फ़ाइलों के लिए अच्छी तरह से काम करता है, लेकिन यह फ़ॉन्ट फ़ाइलों के लिए काम नहीं करता है ।

आपको @VKen उत्तर: https://stackoverflow.com/a/25305915/618464 में दिए गए पैटर्न का उपयोग करके कोर्स को अनुमति देने के लिए डोमेन निर्दिष्ट करना होगा

तो, इस का उपयोग करें :

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
<CORSRule>
    <AllowedOrigin>*</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
<CORSRule>
    <AllowedOrigin>https://*.mydomain.com</AllowedOrigin>
    <AllowedMethod>GET</AllowedMethod>
    <MaxAgeSeconds>3000</MaxAgeSeconds>
    <AllowedHeader>*</AllowedHeader>
</CORSRule>
</CORSConfiguration>

अपने डोमेन के लिए "mydomain.com" को बदलना न भूलें।

इसके बाद CloudFront cache (CloudFront / Invalidations / Create Invalidation) को अमान्य करें और यह काम करेगा।

— educoutinho
स्रोत

6

मेरे मामले में, मैंने कॉर्स कॉन्फ़िगरेशन में XML नाम स्थान और संस्करण को परिभाषित नहीं किया था। काम करने वालों को परिभाषित करना।

बदला हुआ

<CORSConfiguration>

सेवा

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">

— गौरव तोषनीवाल
स्रोत

मेरे लिए भी काम करता है। मेरे फोंट को बाल्टी पर ही होस्ट किया जाता है।

— खामेलियोन

डिफ़ॉल्ट टेम्प्लेट स्वचालित रूप से शामिल क्यों नहीं होता है यह मेरे से परे है।

— CoatedMoose

4

एक बेहतर और आसान तरीका है!

मैं व्यक्तिगत रूप से इस समस्या को हल करने के लिए अपने DNS उप डोमेन का उपयोग करना पसंद करता हूं। अगर मेरी सीडीएन sdf73n7ssa.cloudfront.net के बजाय cdn.myawesomeapp.com के पीछे है तो ब्राउज़र क्रॉस डोमेन सुरक्षा समस्याओं के रूप में उन्हें फ्रीकआउट करने और उन्हें ब्लॉक करने के लिए नहीं जा रहे हैं।

अपने एडडाउन क्लाउडफ्रंट डोमेन के लिए अपने उपडोमेन को इंगित करने के लिए, एडब्ल्यूएस क्लाउडफ्रंट कंट्रोल पैनल पर जाएं, अपने क्लाउडफ्रंट वितरण का चयन करें और अपने सीडीएन उपडोमेन को वैकल्पिक डोमेन नाम (CNAME) क्षेत्र में दर्ज करें। Cdn.myawesomeapp.com जैसा कुछ करेंगे।

अब आप अपने DNS प्रदाता (जैसे एडब्ल्यूएस रूट 53) पर जा सकते हैं और sdf73n7ssa.cloudfront.net की ओर इशारा करते हुए cdn.myawesomeapp.com के लिए CNAME बना सकते हैं।

http://blog.cloud66.com/cross-origin-resource-sharing-cors-blocked-for-cloudfront-in-rails/

— msroot
स्रोत

यह एसएसएल को तोड़ देता है या एसएसएल के साथ करने के लिए बहुत पैसा खर्च होता है इसलिए बहुत से लोग ऐसा नहीं करते हैं।

— maletor

4

इस विन्यास ने मेरे लिए काम किया। मैं ऑब्जेक्ट को सूचीबद्ध कर सकता हूं, पुनः प्राप्त कर सकता हूं, अपडेट कर सकता हूं और हटा सकता हूं।

<?xml version="1.0" encoding="UTF-8"?>
<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
  <CORSRule>
    <AllowedOrigin>http://localhost:3000</AllowedOrigin>
    <AllowedMethod>HEAD</AllowedMethod>
    <AllowedMethod>GET</AllowedMethod>
    <AllowedMethod>PUT</AllowedMethod>
    <AllowedMethod>POST</AllowedMethod>
    <AllowedMethod>DELETE</AllowedMethod>
    <AllowedHeader>*</AllowedHeader>
    <ExposeHeader>ETag</ExposeHeader>
    <ExposeHeader>x-amz-meta-custom-header</ExposeHeader>
  </CORSRule>
</CORSConfiguration>

— शाहिद
स्रोत

आपको डोमेन बदलने की आवश्यकता है, जैसा कि मैंने लोकलहोस्ट से परीक्षण किया था, बस इस पृष्ठ को कोर के

— शाहिद

1

<ifModule mod_headers.c>

   Header set Access-Control-Allow-Origin: http://domainurl.com

</ifModule>

सरल उपाय

— O-mkar
स्रोत

साझा करने के लिए धन्यवाद! मुझे इस हेडर को केवल क्लाउड स्टोरेज के लिए स्थिर संपत्ति अपलोड करते समय 'मेटा-डेटा' के रूप में जोड़ने का विचार दिया । (हालांकि उस तरह से यह केवल 1 या इसके साथ काम करेगा )particular domainall domains

— विनय विस्

0

मेरे स्प्रिंग बूट एप्लिकेशन (सर्वर) को पुनरारंभ करने से मेरे लिए समस्या हल हो गई।

मैंने S3 पर CORS को सही ढंग से कॉन्फ़िगर किया था। कर्ल मूल हेडर के साथ सही प्रतिक्रिया दे रहा था। सफारी सही ढंग से फ़ॉन्ट ला रही थी। यह केवल क्रोम था जो कॉर्स को स्वीकार करने के लिए तैयार नहीं था।

निश्चित नहीं कि व्यवहार का क्या कारण है। इफ-संशोधित-चूंकि के साथ करने के लिए कुछ होना चाहिए

— सुजीत कामठे
स्रोत

0

यह फोंट से संबंधित नहीं है, बल्कि छवियों के लिए है, यह एक किनारे का मामला हो सकता है, लेकिन जैसा कि मेरे साथ हुआ है, यह दूसरे के साथ भी हो सकता है। मैं इसे यहाँ छोड़ दूँगा उम्मीद करता हूँ कि यह किसी की मदद करेगा:

यदि आप इस परिदृश्य में हैं "मैंने जो कुछ भी बताया है वह सब किया है, लेकिन यह अभी भी काम नहीं करेगा" क्रोम और सफारी में यह कैश संबंधी समस्या है। मान लें कि आपके सर्वर में एक उचित CORS कॉन्फ़िगरेशन सेट है:

<CORSConfiguration xmlns="http://s3.amazonaws.com/doc/2006-03-01/">
    <CORSRule>
        <AllowedOrigin>*</AllowedOrigin>
        <AllowedMethod>GET</AllowedMethod>
        <MaxAgeSeconds>3000</MaxAgeSeconds>
    </CORSRule>
</CORSConfiguration>

और फ़ायरफ़ॉक्स में सब कुछ ठीक काम करता है, लेकिन क्रोम और सफारी में ऐसा नहीं है। यदि आप एक सरल टैग और js छवि तत्व src दोनों से अपने दूरस्थ छवि पथ तक पहुँच रहे हैं <img src="http://my.remote.server.com/images/cat.png">, तो निम्न तरीके से:

var myImg = new Image()
myImg.crossOrigin = 'Anonymous'
myImg.onload = () => {
  // do stuff (maybe draw the downloaded img on a canvas)
}
myImg.src = 'http://my.remote.server.com/images/cat.png'

आपको No 'Access-Control-Allow-Origin'Chrome और Safari में त्रुटि प्राप्त हो सकती है । ऐसा इसलिए होता है क्योंकि पहले <img>किसी तरह ब्राउज़र कैश को गड़बड़ कर देता है, और जब आप बाद में उसी छवि को एक्सेस करने की कोशिश कर रहे होते हैं (इन-कोड इमेज एलिमेंट पर), यह बस टूट जाता है। इससे बचने के लिए, आप एक .src पथ में एक काल्पनिक GET परम जोड़ सकते हैं, ताकि ब्राउज़र को छवि को फिर से अनुरोध करने और इस तरह से कैश का उपयोग करने से बचने के लिए मजबूर किया जा सके:

<img src="http://my.remote.server.com/images/cat.png?nocache=true"></img>

— निकोला एलिया
स्रोत

-1

हां बिल्कुल। फ़ायरफ़ॉक्स फोंट के लिए कॉर्स का समर्थन करता है, ठीक उसी तरह जैसे युक्ति की आवश्यकता है http://dev.w3.org/csswg/css3-fonts/#allowing-cross-origin-font-loading

— बोरिस ज़बर्स्की
स्रोत

आपकी त्वरित प्रतिक्रिया के लिए धन्यवाद, बोरिस Zbarsky। क्या आप S3 CORS सेटिंग्स के लिए कुछ उदाहरण विन्यास दिखा पाएंगे?

— वीकेन

मैंने कभी भी S3 को कॉन्फ़िगर करने पर ध्यान नहीं दिया है ... जहाँ तक HTTP स्तर पर भेजने के लिए है, यदि आप इसके साथ ठीक हैं तो फ़ॉन्ट फ़ाइलों के लिए HTTP प्रतिक्रिया में "Access-Control-Allow-Origin: *" भेजना कार्य करना चाहिए।

— बोरिस ज़बर्स्की

धन्यवाद, मैं यह पता लगाने की कोशिश कर रहा हूं कि एस 3 कॉर्स कॉन्फ़िगरेशन के साथ उस सेटिंग को कैसे करना है।

— वीकेन