სანამ პროქსის პარამეტრს საჯარო რეპოზიტორში ჩასვამთ
გამოყავით პროქსის საბოლოო წერტილი პროქსის სამართავი მონაცემებისგან და ახსენით, რატომ არ იძლევა პირველის გამოქვეყნება წვდომის კონტროლს.
კონფიგურაციის ფაილში პროქსის ჰოსტის სახელი არ არის იგივე, რაც პროქსის პაროლი. რომელიმეს გამოქვეყნება გააზრებულ გადაწყვეტილებას იმსახურებს, მაგრამ შედეგები განსხვავებულია.
საბოლოო წერტილი მკითხველს ეუბნება, სად შეიძლება იყოს სერვისი ხელმისაწვდომი. URL, როგორიცაა http://name:[email protected]:8080, მათ ასევე აძლევს გამოსაყენებელ სამართავ მონაცემებს. ის არასოდეს უნდა ჩაითვალოს უვნებლად მხოლოდ იმიტომ, რომ მისამართს ჰგავს.
დამალული მისამართი წვდომის პოლიტიკა არ არის
კერძო პროქსის სჭირდება მის მომხმარებლებზე მორგებული კონტროლი: აუტენტიფიკაცია, დაშვებული კლიენტური ქსელები და დანიშნულების შეზღუდვები. მისამართის რეპოზიტორის გარეთ შენახვა მათ არ ცვლის. საჯაროდ ხელმისაწვდომი სერვისი შეიძლება აღმოჩენილი იყოს ისე, რომ არავინ წაიკითხოს თქვენი კონფიგურაცია.
პირიქით, სერვისის მისამართის გამოქვეყნება არ ამტკიცებს, რომ ის ღიაა. საბოლოო წერტილმა შეიძლება კვლავ მოითხოვოს სამართავი მონაცემები ან ხელმისაწვდომი იყოს მხოლოდ განკუთვნილი ქსელიდან. გადახედეთ რეალურ წვდომის საზღვარს იმის ნაცვლად, რომ ჩათვალოთ, რომ საიდუმლოება და აუტენტიფიკაცია ერთსა და იმავეს ნიშნავს.
გასაზიარებელი მაგალითებისთვის გამოიყენეთ დოკუმენტაციის ჰოსტის სახელები და გამოტოვეთ საიდუმლოებები. კერძო პარამეტრები შეინახეთ პროექტის დამკვიდრებულ საიდუმლოების ან ლოკალური კონფიგურაციის მექანიზმში. ფრთხილად იყავით გენერირებულ ფაილებთან და დაკოპირებულ დიაგნოსტიკურ ჟურნალებთან, რომლებიც შეიძლება შეიცავდეს სრულ URL-ს სამართავი მონაცემებით.
თუ სამართავი მონაცემები გამჟღავნდა, ჯერ მოაცილეთ მათი სარგებლიანობა გაუქმებით ან შეცვლით. უახლესი ფაილის რედაქტირება არ შლის ასლებს, წინა commit-ებს ან ქეშირებულ შიგთავსს. GitHub-ის მგრძნობიარე მონაცემების სახელმძღვანელო ხსნის, რატომ არის ისტორიის გასუფთავება ცალკე ამოცანა.
სასარგებლო მიმოხილვა ამოწმებს ორივე მხარეს: რა წვდომას იძლევა გამოქვეყნებული ინფორმაცია და რჩება თუ არა პროქსი შეზღუდული მაშინაც, როცა მისი მისამართი ცნობილია.