શેર કરેલા સબડોમેન, બે પ્રવેશદ્વાર: કોણ કયા રેકોર્ડ જુએ છે?

ક્લિનિક A અને ક્લિનિક B એક કોડબેઝ, બે સબડોમેન અને ઓફિસ તથા VPN ના મુલાકાતીઓનું મિશ્રણ વહેંચે છે. નેટવર્ક ટીમો સામાન્ય રીતે બે પ્રવેશદ્વાર અલગ રીતે ગોઠવે છે, અને તે ઠીક છે, જ્યાં સુધી એપ્લિકેશન એમ ન કરે. નીચેની ચકાસણીઓ એપ્લિકેશનમાં જ હોવી જોઈએ અને વિનંતીએ કયું દરવાજો વાપર્યું તે ધ્યાનમાં લીધા વિના એકસરખું વર્તવું જોઈએ.

પ્રથમ: હોસ્ટનામ ફક્ત ટેનન્ટનું નામ આપે છે

વિનંતી કરેલ હોસ્ટનામને એડમિનિસ્ટ્રેટર જે મેપિંગ રાખે છે તેની સાથે ઉકેલો, અને અજાણ્યું કંઈપણ નકારો. કાચા હેડરને બદલે ફ્રેમવર્કના માન્ય હોસ્ટ મૂલ્યનો ઉપયોગ કરો, જેથી બનાવટી Host લુકઅપ કી ઇન્જેક્ટ કરી ન શકે. સફળ મેળ કોડને કહે છે કે કઈ ટેનન્ટ ગોઠવણી અને કઈ બ્રાન્ડિંગ લોડ કરવી. તે એ વિશે કંઈ કહેતું નથી કે કૉલર તે ટેનન્ટનો ડેટા જોઈ શકે છે કે નહીં. એ બીજો પ્રશ્ન અલગ ઇનપુટ સાથે અલગ ફંક્શનમાં રાખો.

એક જ હોસ્ટનામ લુકઅપમાંથી સંદર્ભ અને પરવાનગી બંને પરત કરતું વહેંચાયેલ સહાયક ફંક્શન એ બગની શરૂઆત છે.

બીજું: સભ્યપદ સત્રમાંથી આવે છે

પ્રમાણિત વપરાશકર્તાના સક્રિય સભ્યપદ શોધો અને તેમને પ્રથમ ચકાસણીના ટેનન્ટ સાથે સરખાવો. બંને ક્લિનિકમાં જોડાયેલ વપરાશકર્તા બદલી શકે છે, પરંતુ બદલી એ વિનંતીના સંદર્ભમાં નોંધાયેલી સ્પષ્ટ ક્રિયા હોવી જોઈએ, URL થી અનુમાન નહીં. એક ક્લિનિકમાં જોડાયેલ અને બીજી માંગતા વપરાશકર્તાને નકારવામાં આવે છે, જેમાં ડાઉનલોડ અને API કૉલનો પણ સમાવેશ થાય છે.

રેકોર્ડ ઓળખકર્તા અને ટેનન્ટ પરિમાણ સંપાદિત કરીને નકારાત્મક કેસ ચકાસો. જો બંનેમાંથી કોઈ પણ ફેરફાર ડેટા પરત કરે, તો અવકાશ વિનંતીમાંથી વાંચવામાં આવે છે, ચકાસાયેલ સભ્યપદમાંથી નહીં.

કૂકી અવકાશ અને એકલ સાઇન-ઓન નક્કી કરે છે કે ખાતું ક્યાં રજૂ કરી શકાય. તે નક્કી કરતા નથી કે તે ખાતું શું વાંચી શકે.

ત્રીજું: નેટવર્ક વ્યક્તિ વિશે કંઈ સાબિત કરતું નથી

VPN ગેટવે ટનલને પ્રમાણિત કરે છે, અને જાહેર પરવાનગી-યાદી સરનામા શ્રેણીને પ્રમાણિત કરે છે. બંનેમાંથી કોઈ વ્યક્તિને ઓળખતું નથી. NAT ઘણા વપરાશકર્તાઓને એક સ્રોત સરનામામાં સમેટે છે, અને ઓફિસ શ્રેણી ઇમારતમાંના દરેક માટે એ જ કરે છે. બંનેને પરિવહન-તથ્ય તરીકે ગણો અને અધિકૃતિ એપ્લિકેશનમાં રાખો, અથવા એવા સંકલનમાં રાખો જે ઓળખ સ્પષ્ટપણે દાવો કરે અને તે રીતે સમીક્ષા થાય.

DNS ત્રીજું પરિવહન-તથ્ય છે. ખાનગી જવાબને ખાનગી માર્ગની જરૂર છે, અને જાહેર ફ્રન્ટએન્ડને સમર્થિત મૂળ-માર્ગની જરૂર છે. તેમાંથી કોઈ પરવાનગી ધરાવતું નથી.

દીવાલ પર રાખવાનું એક વાક્ય: નેટવર્ક નક્કી કરે છે કે વિનંતી કેવી રીતે આવે છે, અને એપ્લિકેશન નક્કી કરે છે કે તે શું વાંચી શકે.

ચોથું: બંને પ્રવેશદ્વાર પર મેટ્રિક્સ ચલાવો

નિયંત્રિત ખાતાં વાપરીને A ને A પર, B ને B પર, A ને B પર, અજાણ્યું હોસ્ટનામ અને સભ્યપદ વિનાનું પ્રમાણિત ખાતું ચકાસો. ચોથું અને પાંચમું બંધ રીતે નિષ્ફળ જવું જોઈએ અને ક્યારેય ડિફૉલ્ટ ટેનન્ટ પર પાછા ન પડવું જોઈએ. એ જ મેટ્રિક્સ VPN પ્રવેશદ્વાર દ્વારા પણ ચલાવો, દરેક ખાતા માટે એક સત્ર-જાર સાથે:

curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-b.example.com/records/42
curl -s -o /dev/null -w '%{http_code}' -b jar.txt https://clinic-a.example.com/records/42

પછી પરવાનગી-યાદીમાં એક એન્ટ્રી બદલો અને ફરી ચલાવો. ખસતું પરિણામ એટલે નેટવર્ક નિયંત્રણ અધિકૃતિનો નિર્ણય લઈ રહ્યું છે.

ફ્રન્ટએન્ડમાં કોઈપણ ફેરફાર પછી મેટ્રિક્સ પુનરાવર્તિત કરો, કારણ કે ચકાસણી છોડી દેતો બીજો કોડ-માર્ગ એ આ સીમા ધોવાઈ જવાનો સૌથી સામાન્ય રસ્તો છે. અપેક્ષિત પરિણામ કંટાળાજનક છે: દરેક પ્રવેશદ્વાર એ જ જવાબો આપે છે.