பொது படிவ சமர்ப்பிப்புகளை தனியுரிம வலையமைப்பிற்கு இறக்குமதி செய்வது எப்படி

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

சமர்ப்பிப்பு வந்திறங்கும் இடத்திலிருந்து தொடங்குங்கள்

உலாவி ஒரு பொது முனைக்கு அனுப்புகிறது, அது கட்டுப்படுத்தப்பட்ட பெறுதல் சேமிப்பகத்தில் ஒரு வரியை எழுதி ஒப்புதலுக்கு மேல் எதையும் திருப்பித் தராது. அந்த சேமிப்பகமே ஒப்படைப்பு புள்ளி, பொது அடுக்கு எழுதக்கூடிய ஒரே விஷயம் அதுவாகவே இருக்க வேண்டும். மூலத் தரவை அங்கே மாற்றமின்றி, அது வந்த நேரம் மற்றும் நிலையான பதிவு அடையாளங்காட்டியுடன் வைத்திருங்கள்.

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

curl --silent --fail \
  --cert /etc/importer/client.crt --key /etc/importer/client.key \
  "https://intake.corp.internal/api/pending?limit=20" \
  -o /var/lib/importer/pending.json

இறக்குமதியாளருக்கு தேவையான அதிகாரத்தை மட்டும் கொடுங்கள்

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

பணியாளர் எந்த மூலத்திலிருந்து படிக்கலாம் என்பதையும் வரம்பிடுங்கள். செயலாக்கம் ஒரு வரிசை அல்லது பரிமாற்ற சேவையைப் பயன்படுத்தினால், அந்த சேவை அதன் சொந்த அங்கீகாரத்தையும் அணுகல் கொள்கையையும் வைத்திருக்கும், ஏனெனில் VPN பேலோடுக்குள் எதையும் அங்கீகரிக்காது.

குறுகிய கால செயல்பாடும் அதே மதிப்பாய்விலிருந்து விலக்கப்படவில்லை. அது இயங்கும் போது அதன் வலையமைப்பு நிலையும் சான்றுகளும் இன்னும் அதிகாரம் தருகின்றன, குறுகிய ஆயுள் சாளரத்தை சுருக்குகிறது மட்டுமே. அடையாளம் எந்த செயல்பாடுகளை செய்யலாம் என்பதை தீர்மானிப்பதற்கு ஆயுள் மாற்றல்ல.

உள்ளே எதுவும் மாறுவதற்கு முன் சரிபார்க்கவும்

பொது படிவ புலங்கள் எதிர்மறை நிரூபிக்கப்படும் வரை தாக்குபவரால் கட்டுப்படுத்தப்படும் உரை, மேலும் OWASP இன் உள்ளீட்டு சரிபார்ப்பு வழிகாட்டுதல் அதே காரணத்திற்காக பின்தள ஊட்டங்களை நம்பமுடியாத மூலங்களில் சேர்க்கிறது. மறையாக்கப்பட்ட பரிமாற்றம் பைட்டுகள் பாதுகாப்பாக வந்தன என்று கூறுகிறது, அவை அனுமதிக்கப்பட்ட கோரிக்கையை விவரிக்கின்றன என்று அல்ல. எந்த சிறப்புரிமை படிநிலைக்கும் முன் பகுப்பாய்வு செய்து சரிபார்க்கவும், அதனால் மோசமான வரி செயல்படக்கூடிய குறியீட்டு பாதையை அடையாது.

அனுமதிக்கப்பட்ட புலங்கள், அவற்றின் வடிவங்கள், அளவுகள் மற்றும் கடைபிடிக்க வேண்டிய வணிக விதிகளை வரையறுக்கவும். ஒரு தேதி சரியாக வடிவமைக்கப்பட்டிருந்தாலும் கோரப்பட்ட செயல்பாட்டிற்கு தவறாக இருக்கலாம், உள் கணக்கு அல்லது ஒப்புதல் நிலையை பெயரிடும் பேலோடு அவற்றில் எதையும் தனக்குத்தானே வழங்க முடியக்கூடாது.

நிராகரிக்கப்பட்ட வரிகளை திருத்தத்தை ஊகிப்பதற்குப் பதிலாக மதிப்பாய்வு முடிவுக்கு அனுப்புங்கள், அல்லது அவற்றை ஷெல் அல்லது மூல தரவுத்தள இடைமுகத்திற்கு அனுப்ப வேண்டாம். பதிவு அடையாளங்காட்டி மற்றும் தோல்வியடைந்த விதியை பதிவு செய்யுங்கள், விண்ணப்பதாரர் தட்டச்சு செய்த ஒவ்வொரு புலத்தையும் அல்ல.

ஒரு செயல்பாட்டில் மறுமுயற்சி புள்ளியை உருவாக்குங்கள்

முதல் ஒப்புதல் தொலைந்ததால் submission-1042 பதிவு இரண்டு முறை இழுக்கப்பட்டால், பணியாளருக்கு மூல பதிவையும் அதன் பதிவு செய்யப்பட்ட முடிவையும் அடையாளம் காண நிலையான வழி தேவை. வேலையை ஒரு முறை இயக்கும் அட்டவணை ஒவ்வொரு வரியும் ஒரு முறை பயன்படுத்தப்பட்டது என்பதை நிரூபிக்காது. இரட்டை வழங்கல் சாதாரணம், எனவே வடிவமைப்பு அதை உள்வாங்க வேண்டும்.

உள் பயன்பாட்டின் சொந்த பரிவர்த்தனை மற்றும் நகல் கையாளுதல் பொறிமுறையைப் பயன்படுத்துங்கள், மூல அடையாளங்காட்டி, முடிவு மற்றும் ஒப்புதலை ஒரே ஒத்திசைவான வரிசையில் வைத்திருங்கள். உத்தேசிக்கப்பட்ட செயல்பாடு பதிவு செய்யப்பட்ட அல்லது நிலையாக ஒதுக்கப்பட்ட பிறகே ஒப்புதல் அளியுங்கள், பைட்டுகள் பதிவிறக்கப்பட்டதால் மட்டும் பெறுதல் வரியை ஒருபோதும் நீக்க வேண்டாம்.

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

for f in fixtures/valid-submission.json fixtures/bad-date.json; do
  curl --silent --fail --cert /etc/importer/client.crt \
    -X POST --data @"$f" https://intake.corp.internal/api/records
done
curl --silent --fail --cert /etc/importer/client.crt \
  -X POST --data @fixtures/valid-submission.json https://intake.corp.internal/api/records

முதல் இரண்டு வரிகளும் வெவ்வேறு உள் நிலைகளில் முடிய வேண்டும், மூன்றாவது இரண்டாவதை உருவாக்குவதற்குப் பதிலாக அந்த மூல பதிவுக்கு ஏற்கனவே பதிவு செய்யப்பட்ட அடையாளங்காட்டியை திருப்பித் தர வேண்டும். வேறு எந்த முடிவும் இறக்குமதி இன்னும் மீளச்செய்யக்கூடியதல்ல என்பதைக் குறிக்கிறது.