ஒரு குழு பகிரப்பட்ட environment கோப்பில் ஒரு bypass சரத்தை இடுகிறது. curl நேரடியாகச் செல்கிறது, மற்றொரு பயன்பாடு proxy-ஐப் பயன்படுத்துகிறது, கொள்கலன் மீண்டும் வேறுவிதமாக நடந்துகொள்கிறது. பகிரப்பட்ட கோப்பு அதே எழுத்துகளை விநியோகித்தது. அது ஒரு பகிரப்பட்ட parser-ஐ விநியோகிக்கவில்லை.

நிலைத்திருக்கும் பொருள் கொள்கையே: எந்த இடங்கள் நேரடியாக இருக்க வேண்டும், எந்த நிபந்தனைகளில்? அதை ஒவ்வொரு நிரலுக்கும் தேவையான சரத்திலிருந்து தனியாக வையுங்கள்.

முதலில் எதிர்பார்க்கப்படும் வழித்தடங்களை எழுதுங்கள்

எளிய வெற்றிகளை மட்டுமல்ல, எல்லை நிலைகளையும் சேர்த்த பிரதிநிதி முகவரிகளைப் பயன்படுத்துங்கள்:

இடத்தின் வடிவம்கொள்கை உரிமையாளருக்கான கேள்வி
தாய் domainஇது bypass செய்யப்பட வேண்டுமா, அல்லது அதன் குழந்தைகள் மட்டுமா?
ஒரு துணை domainஅது அதே வழித்தடத்தை மரபுரிமையாகப் பெறுகிறதா?
நேரடியாக எழுதப்பட்ட தனியார் IPஅந்த முகவரி இந்த வாடிக்கையாளரிடமிருந்து நேரடியாக அணுகக்கூடியதா?
hostname-க்கு கீழ் அதே சேவைபெயர் அடிப்படையிலான மற்றும் முகவரி அடிப்படையிலான கோரிக்கைகள் ஒத்துப்போக வேண்டுமா?
மற்றொரு சேவை portவிலக்கு host-ஐ பாதுகாக்கிறதா அல்லது ஒரு listener-ஐ மட்டுமா?

பின்னர் பயனர்களை அடையாளம் காணுங்கள்: image இழுக்கும் daemon, கொள்கலனுக்குள் உள்ள நிரல், ஒரு மொழியின் HTTP நூலகம் மற்றும் ஊடாடும் உலாவி அனைத்தும் தனித்தனி உள்ளீடுகளாக இருக்கலாம். Docker வாடிக்கையாளர் proxy கட்டமைப்பு கொள்கலனின் environment மதிப்புகளை நிரப்ப முடியும், உள்ளே உள்ள ஒவ்வொரு வாடிக்கையாளரும் அதே பொருத்தல் விதிகளை செயல்படுத்த வேண்டியதில்லை.

கண்மூடித்தனமாக நகலெடுக்காமல் மொழிபெயர்க்கவும்

உண்மையான வேறுபாட்டின் ஒரு பதிவுசெய்யப்பட்ட எடுத்துக்காட்டு தாய்-domain எல்லை. curl-இன் domain விலக்கு பெயரிடப்பட்ட domain மற்றும் பொருந்தும் குழந்தைகளை உள்ளடக்குகிறது. .NET-இன் environment கொள்கை வெற்று பெயரையும் முன் புள்ளியுடன் கூடிய துணை domain வடிவத்தையும் வேறுபடுத்துகிறது. „எப்போதும் முன் புள்ளியைச் சேர்“ என்ற பொதுவான விதி இரு கொள்கைகளையும் நம்பகமாக வெளிப்படுத்த முடியாது.

IP வரம்பு ஆதரவும் பயனர் மற்றும் அவரது பதிப்பைப் பொறுத்தது. புதிய தனித்த curl உள்ள இயந்திரம் பழைய libcurl உடன் இணைக்கப்பட்ட பயன்பாட்டையோ, முற்றிலும் வேறு நூலகத்தைப் பயன்படுத்தும் வாடிக்கையாளரையோ இன்னும் இயக்க முடியும். இயக்க முறைமை வெளியீடு முழுமையான வாடிக்கையாளர் பட்டியல் அல்ல.

ஒவ்வொரு பயனருக்கும், ஆதரிக்கப்படும் கட்டமைப்பு இடைமுகத்தையும் நோக்கமான வழித்தடங்களின் மிகச் சிறிய வெளிப்பாட்டையும் பதிவு செய்யுங்கள். யாரும் விளக்க முடியாத அர்த்தமுள்ள திறமையான வடிவத்தை விட சிறிய தெளிவான host பட்டியல் சிறந்ததாக இருக்கலாம்.

கட்டமைப்பு சான்றை இணைப்பு சான்றிலிருந்து தனியாக வையுங்கள்

பகுப்பாய்வு செய்யப்பட்ட அமைப்பு அல்லது வழித்தட-முடிவு API நிரல் எதைத் தேர்ந்தெடுத்தது என்பதைக் காட்டலாம். கோரிக்கையின் விளைவு அந்த வழித்தடம் பயன்படுத்தக்கூடியதா என்பதைப் பின்னர் காட்டுகிறது. .NET-இல், HttpClient.DefaultProxy.IsBypassed இயல்புநிலை proxy பயன்பாட்டில் உள்ள கொள்கையாக இருக்கும்போது அந்தக் கட்டமைப்புப் பக்கச் சரிபார்ப்பை வழங்குகிறது. கோரிக்கை நேரம் முடிந்தது என்பதற்காக மட்டும் அணுக முடியாத நேரடி சேவையை bypass-parser தோல்வியாகக் கண்டறிய வேண்டாம்.

வாடிக்கையாளரையோ அடிப்படை image-ஐயோ புதுப்பிக்கும்போது எல்லை இடங்களைத் தக்கவைத்துக் கொள்ளுங்கள். கோப்பில் ஏன் ஒத்த தோற்றமுள்ள இரு domain உள்ளீடுகள் உள்ளன என்பதை முழுக் குழுவும் மீண்டும் கண்டுபிடிக்கத் தேவையில்லாமல், அவை எதிர்கால இணக்கத்தன்மை மாற்றங்களைத் தெரியப்படுத்துகின்றன.

தொடர்புடைய கட்டுரைகள்