2010-03-31 30 views
14

मैंने एक नमूना एप्लिकेशन निकाल दिया जो छवि होस्टिंग के लिए अमेज़ॅन एस 3 का उपयोग करता है। मैं इसे काम करने में कामयाब रहा। एप्लिकेशन github.com पर होस्ट किया गया है। एप्लिकेशन आपको प्रोफाइल फोटो वाले उपयोगकर्ताओं को बनाने देता है। जब आप फोटो अपलोड करते हैं, तो वेब एप्लिकेशन इसे आपके स्थानीय फ़ाइल सिस्टम की बजाय अमेज़ॅन एस 3 पर संग्रहीत करता है। (बहुत महत्वपूर्ण यदि आप heroku.com पर होस्ट)अमेज़ॅन एस 3 पर कम छवियों को होस्ट करने के लिए कैसे कम सार्वजनिक लेकिन पूरी तरह से निजी नहीं है?

हालांकि, जब मैं पेज के ब्राउज़र में एक "दृश्य स्रोत" किया था मैंने देखा है कि चित्र का URL S3 बाल्टी में एक अमेज़न S3 यूआरएल है कि मैं करने के लिए सौंपा था अप्प। मैंने & को यूआरएल चिपकाया और उसी ब्राउज़र में तस्वीर को देखने में सक्षम था, और दूसरे ब्राउज़र में जिसमें मेरे वेब ऐप या अमेज़ॅन एस 3 के लिए कोई खुला सत्र नहीं था।

क्या कोई तरीका है कि मैं उस यूआरएल (और छवि) तक पहुंच प्रतिबंधित कर सकता हूं ताकि यह केवल मेरे अनुप्रयोगों में लॉग इन किए गए ब्राउज़र तक पहुंच सके?

अमेज़ॅन एसीएल के बारे में मुझे मिली अधिकांश जानकारी केवल मालिक या अमेज़ॅन या अमेज़ॅन एस 3 के साथ प्रमाणित उपयोगकर्ताओं के समूह या गुमनाम रूप से प्रमाणित उपयोगकर्ताओं के समूहों के लिए पहुंच के बारे में बात करती है।

संपादित ---- अपडेट 7 जुलाई, 2010

अमेज़न S3 वस्तुओं और बाल्टी के लिए उपयोग को प्रतिबंधित करने के just announced अधिक तरीकों है। अन्य तरीकों से, अब आप HTTP रेफरर को अर्हता प्राप्त करके एस 3 ऑब्जेक्ट तक पहुंच प्रतिबंधित कर सकते हैं। यह दिलचस्प लगता है ... जब तक वे अपने डेवलपर दस्तावेज़ अपडेट नहीं करते हैं तब तक मैं इंतजार नहीं कर सकता।

उत्तर

3

एस 3 एक अलग सेवा है और आपके सत्रों के बारे में नहीं जानता है।

सामान्य समाधान उन लाभों और सुरक्षा गुणों को पहचानना है जो प्रत्येक संपत्ति को एक अलग, अद्वितीय, और बहुत लंबी और यादृच्छिक कुंजी निर्दिष्ट करते हैं, जो उस संपत्ति के यूआरएल का हिस्सा बनता है। यदि आप ऐसा चुनते हैं, तो आप यादृच्छिकता के 512 प्रभावी बिट्स के साथ एक कुंजी भी निर्दिष्ट कर सकते हैं, और वह यूआरएल बहुत लंबे समय तक असहनीय रहेगा।

  • क्योंकि कोई है जो समय में t एक परिसंपत्ति की पहुंच है बस भविष्य में संदर्भ के लिए संपत्ति कॉपी कर सकते हैं, यह समझ में आता है यूआरएल को जानते हैं और किसी भी समय संपत्ति का उपयोग करने की है कि व्यक्ति को अनुमति देने के लिए।
  • इसी प्रकार, चूंकि वह व्यक्ति केवल संपत्ति डाउनलोड कर सकता है और इसे दूसरों को वितरित कर सकता है, इसलिए यह समझ में आता है कि उस व्यक्ति को उन लोगों को यूआरएल वितरित करने की इजाजत दी जाए, जिनके लिए वह अन्यथा केवल संपत्ति को वितरित कर लेगा।
  • चूंकि ऐसी सभी पहुंच केवल पढ़ने के लिए है, और चूंकि लिखने वेबसाइट सर्वर तक सीमित हैं, इसलिए इस एक्सेस के किसी भी व्यक्ति से दुर्भावनापूर्ण "हैकिंग" का कोई खतरा नहीं है।

आपको यह निर्धारित करना होगा कि यह पर्याप्त सुरक्षा है या नहीं। यदि ऐसा नहीं है, तो शायद S3 आपके लिए नहीं है, और हो सकता है कि आपको अपनी छवियों को अपने डेटाबेस में बाइनरी कॉलम के रूप में स्टोर करने की आवश्यकता हो और उन्हें मेमकैच में कैश करें, जिसे आप हेरोकू पर कर सकते हैं।

+0

@ जस्टिस - एक पूर्ण और बहुत ही तर्कसंगत उत्तर के लिए धन्यवाद। यह बिल्कुल तर्क है कि मुझे एस 3 का उपयोग करने की आवश्यकता है। एस 3 पर संग्रहीत संपत्ति सुपर-क्रिटिकल नहीं है, जहां तक ​​गोपनीयता जाती है, और यूआरएल केवल लॉग-इन उपयोगकर्ताओं के लिए उपलब्ध हैं। मुझे लगता है कि मुझे यादृच्छिक संख्या उत्पन्न करने के लिए किसी प्रकार का नमकीन हैश करना है। तार्किक बिंदुओं के लिए –

+1

+1 एक। संसाधन के लिए प्रत्येक अद्यतन के लिए एक नया यादृच्छिक यूआरएल उत्पन्न करना भी महत्वपूर्ण है। –

1

मुझे लगता है कि आप जो कर सकते हैं वह सबसे अच्छा है जो drop.io करता है। जबकि डेटा किसी के लिए सिद्धांत रूप से सुलभ है, तो आप इसे एक बड़ा और यादृच्छिक यूआरएल देते हैं। कोई भी जो यूआरएल जानता है उसे एक्सेस कर सकता है, लेकिन आपका एप्लिकेशन यूआरएल देखने के लिए नियंत्रित करता है।

अस्पष्टता के माध्यम से सुरक्षा की तरह।

आप इसे यूआरएल में शामिल पासवर्ड के रूप में सोच सकते हैं। इसका मतलब है कि यदि आप सुरक्षा के बारे में गंभीर हैं, तो आपको यूआरएल को गोपनीय जानकारी के रूप में व्यवहार करना होगा। आपको यह सुनिश्चित करना होगा कि ये लिंक खोज इंजन पर भी रिसाव न करें।

एक्सेस अधिकारों को रद्द करना भी मुश्किल है। केवल एक चीज जो आप कर सकते हैं वह एक यूआरएल अवैध है और एक नया असाइन करें।

9

फ़ाइलों जहां गोपनीयता वास्तव में मायने रखती है के लिए, हम इस संभाल इस प्रकार है:

  • फ़ाइलें एक निजी एसीएल के साथ जमा हो जाती है, जिसका अर्थ है कि केवल अधिकृत एजेंट
  • एक तक पहुंचने के लिए डाउनलोड (या अपलोड) कर सकते हैं उन्हें फ़ाइल, हम http://myapp.com/download/{s3-path}, जहां download एक नियंत्रक से मेल खाती है (MVC अर्थ में)
  • एसीएल उचित रूप में लागू किया जाता है, ताकि केवल लॉग-इन उपयोगकर्ताओं
  • कि नियंत्रक डाउनलोड टी कि नियंत्रक/कार्रवाई का उपयोग कर सकते से लिंक वह एपीआई का उपयोग कर फ़ाइल, फिर, सही माइम-प्रकार, कैश हेडर, फ़ाइल आकार के साथ उपयोगकर्ता के लिए यह धाराओं आदि

इस पद्धति का उपयोग करके आप एक बहुत अधिक बैंडविड्थ का उपयोग करने से आप की जरूरत खत्म हो, लेकिन आप अभी भी भंडारण पर बचाओ। हमारे लिए यह काम करता है, क्योंकि हम बैंडविड्थ की तुलना में अधिक भंडारण से बाहर निकलते हैं।

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

हालांकि, जब मैंने पृष्ठ के ब्राउज़र में "दृश्य स्रोत" किया था, तो मैंने देखा कि तस्वीर का यूआरएल एस 3 बाल्टी में एक अमेज़ॅन एस 3 यूआरएल था जिसे मैंने ऐप को सौंपा था। मैंने & को यूआरएल चिपकाया और उसी ब्राउज़र में तस्वीर को देखने में सक्षम था, और दूसरे ब्राउज़र में जिसमें मेरे वेब ऐप या अमेज़ॅन एस 3 के लिए कोई खुला सत्र नहीं था।

ध्यान रखें कि यह आपके दस्तावेज़ रूट में कहीं और संग्रहीत किसी भी छवि से अलग नहीं है। आपको जिस प्रकार की सुरक्षा की तलाश है, उसे आप की आवश्यकता हो सकती है या नहीं।

+0

यदि आपको * वास्तव में * एसीएल की आवश्यकता है, तो यह निश्चित रूप से यह कैसे करना है।हालांकि, हेरोकू पर, और इन संपत्तियों के लिए पहुंच पैटर्न के आधार पर, यह रणनीति आपको अन्यथा की तुलना में "अपने डायनास को क्रैंक" करने के लिए मजबूर करेगी। – yfeldblum

+0

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

+0

एक बहुत ही पूर्ण उत्तर के लिए धन्यवाद। –

5

अमेज़ॅन के रूबी एसडीके (https://github.com/aws/aws-sdk-ruby) में उपयोगी विधियां हैं जो इसे करने के लिए इसे एक स्नैप बनाती हैं। "url_for" अन्यथा निजी S3 ऑब्जेक्ट के लिए एक अस्थायी पठनीय यूआरएल उत्पन्न कर सकता है।

यहाँ एक पठनीय यूआरएल है कि 5 मिनट के बाद समाप्त हो कैसे बनाया जाता है:।

वस्तु = एडब्ल्यूएस :: S3.new.buckets [ 'बाल्टी'] वस्तुओं [ 'कुंजी']

वस्तु .url_for (: पढ़ें,: समाप्त हो रहा है => 300) .to_s

एडब्ल्यूएस प्रलेखन: http://docs.aws.amazon.com/AWSRubySDK/latest/AWS/S3/S3Object.html#url_for-instance_method

+0

उनके पास PHP एसडीके में हस्ताक्षरित यूआरएल के लिए एक समान सुविधा है। http://docs.aws.amazon.com/aws-sdk-php/guide/latest/service-s3.html#creating-a-pre-signed-url मुझे लगता है कि यह इस पोस्टर के लिए सबसे अच्छा वर्तमान समाधान है समस्या की तरह – Chris