2014-11-01 22 views
29

मुझे हाल ही में एक रेल ऐप मिला है जो संपत्तियों के भंडारण के लिए एस 3 का उपयोग करता है। मैंने सभी संपत्तियों को बिना किसी समस्या के अपने एस 3 बाल्टी में स्थानांतरित कर दिया है। हालांकि, जब मैं नई बाल्टी को इंगित करने के लिए ऐप को बदलता हूं तो मुझे 403 निषिद्ध स्थिति मिलती है।अमेज़ॅन एस 3 बाल्टी 403 निषिद्ध

मेरे S3 बाल्टी निम्न सेटिंग के साथ की स्थापना की है:

अनुमतियां

हर कोई

बाल्टी नीति

{ 
"Version": "2012-10-17", 
"Statement": [ 
    { 
     "Sid": "PublicReadGetObject", 
     "Effect": "Allow", 
     "Principal": "*", 
     "Action": "s3:GetObject", 
     "Resource": "arn:aws:s3:::bucketname/*" 
    } 
] 
} 

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> 
    </CORSRule> 
    <CORSRule> 
     <AllowedOrigin>https://www.appdomain.com</AllowedOrigin> 
     <AllowedMethod>PUT</AllowedMethod> 
     <AllowedMethod>POST</AllowedMethod> 
     <AllowedMethod>DELETE</AllowedMethod> 
     <AllowedHeader>*</AllowedHeader> 
    </CORSRule> 
</CORSConfiguration> 

स्टेटिक वेब होस्टिंग

सक्षम किया गया।

जनता को इन संपत्तियों तक पहुंचने की अनुमति देने के लिए मैं और क्या कर सकता हूं?

उत्तर

19

मुद्दा यह है कि स्थानांतरण this thread के अनुसार किया गया था, जो स्वयं ही कोई मुद्दा नहीं है। यह मुद्दा पिछले डेवलपर से स्थानांतरित करने से पहले फ़ाइलों पर अनुमतियों को बदल नहीं रहा था। इसका मतलब था कि मैं किसी भी फाइल का प्रबंधन नहीं कर सका, भले ही वे मेरी बाल्टी में थे।

समस्याएं पिछली बाल्टी से फ़ाइलों को दोबारा डाउनलोड करके, पुरानी प्रेत फ़ाइलों को हटाने, ताजा फाइलों को फिर से अपलोड करने और फ़ाइलों के सार्वजनिक पढ़ने की अनुमति देने के लिए अपनी अनुमतियों को सेट करके हल की गई थीं।

14

मुझे पता है कि यह एक पुराना धागा है, लेकिन मुझे बस एक ही समस्या का सामना करना पड़ा। मेरे पास महीनों के लिए सब कुछ काम कर रहा था और यह अचानक मुझे 403 Forbidden त्रुटि देने के लिए काम करना बंद कर दिया। यह पता चला कि सिस्टम घड़ी असली अपराधी थी। मुझे लगता है कि एस 3 कुछ प्रकार के समय-आधारित टोकन का उपयोग करता है जिसमें बहुत कम उम्र होती है। और मेरे मामले में मैं बस भाग गया:

ntpdate pool.ntp.org 

और समस्या दूर हो गई। मैं CentOS 6 चला रहा हूं यदि यह किसी भी प्रासंगिकता का है। यह नमूना आउटपुट था:

19 Aug 20:57:15 ntpdate[63275]: step time server ip_address offset 438.080758 sec 

आशा में मदद करता है!

+0

पोस्ट करने के लिए धन्यवाद देते हैं। विंडोज़ के साथ अभी मुझे एक ही समस्या थी। सिस्टम के समय को सुधारने से इसे हल किया गया। –

+3

भगवान आपको आशीर्वाद देते हैं, अच्छे आदमी। और पुराने धागे का जवाब देने में कभी भी संकोच न करें। – Yaroslav

5

यह भी हो सकता है कि अमेज़ॅन दस्तावेज़ों के अनुसार उचित नीति निर्धारित की जानी चाहिए।

http://docs.aws.amazon.com/AmazonS3/latest/dev/WebsiteAccessPermissionsReqd.html

प्रश्न में बाल्टी इस नीति

{ 
    "Version":"2012-10-17", 
    "Statement":[{ 
    "Sid":"PublicReadGetObject", 
     "Effect":"Allow", 
     "Principal": "*", 
     "Action":["s3:GetObject"], 
     "Resource":["arn:aws:s3:::YOUR-BUCKET-NAME/*" 
     ] 
    } 
    ] 
} 
+0

मुझे संसाधन से हटाए गए "/ *" के साथ एक कथन जोड़ना पड़ा। – ram4nd

संबंधित मुद्दे