പ്രോക്സി ക്രെഡൻഷ്യലുകളിലെ ഡൊമെയിൻ-യോഗ്യ ഉപയോക്തൃനാമങ്ങൾ
അസ്പഷ്ടമായ അക്കൗണ്ട് നാമത്തെ വേറിട്ട ഡൊമെയിൻ ഫീൽഡുകളുള്ള API-കളിൽ നിന്ന് വേർതിരിക്കുക, കൂടാതെ URL വാക്യഘടന തൃപ്തിപ്പെടുത്താൻ മാത്രം അക്കൗണ്ട് ഐഡന്റിറ്റി മാറ്റുന്നത് ഒഴിവാക്കുക.
ഒരു ഉത്തരം DOMAIN\ നീക്കം ചെയ്യാൻ പറയുന്നു. മറ്റൊന്ന് അത് ചേർക്കാൻ പറയുന്നു. രണ്ട് മാറ്റങ്ങളും നിങ്ങളുടെ പ്രോക്സിക്ക് തെറ്റായിരിക്കാം.
രണ്ട് ചോദ്യങ്ങളുണ്ട്: സേവനം ഏത് ഐഡന്റിറ്റിയാണ് പ്രതീക്ഷിക്കുന്നത്, തിരഞ്ഞെടുത്ത API ആ ഐഡന്റിറ്റിയെ എങ്ങനെ പ്രതിനിധീകരിക്കുന്നു.
| ഇന്റർഫേസ് | എന്ത് സ്ഥാപിക്കണം |
|---|---|
| ഒരൊറ്റ അക്കൗണ്ട്-നാമ ഫീൽഡ് | ഓപ്പറേറ്റർ സ്വീകരിക്കുന്ന കൃത്യമായ അക്കൗണ്ട് വാക്യഘടന |
| ഡൊമെയിൻ ഫീൽഡുള്ള ക്രെഡൻഷ്യൽ API | ഡൊമെയ്നും ഉപയോക്തൃനാമവും വേറിട്ട് നൽകണമോ |
| URI-യ്ക്കുള്ളിലെ ക്രെഡൻഷ്യൽ ഘടകങ്ങൾ | ഉദ്ദേശിച്ച മൂല്യങ്ങൾ ആ കണ്ടെയ്നറിനായി എങ്ങനെ എൻകോഡ് ചെയ്യണം |
ഉദാഹരണത്തിന്, .NET വേറിട്ട ഉപയോക്തൃനാമം, പാസ്വേഡ്, ഡൊമെയിൻ ആർഗ്യുമെന്റുകളുള്ള NetworkCredential കൺസ്ട്രക്ടർ നൽകുന്നു. ഡൊമെയിൻ വേർതിരിവില്ലാതെ രണ്ട് ഫീൽഡുകളിൽ ഇടുന്നത് സംയോജിത പ്രാമാണീകരണം ക്രമീകരിക്കാനുള്ള കൈമാറാവുന്ന വഴിയല്ല.
Basic പ്രാമാണീകരണം മറ്റൊരു കേസാണ്: സർവർ നൽകിയ അക്കൗണ്ട് ടെക്സ്റ്റ് സ്വന്തം നയപ്രകാരം വ്യാഖ്യാനിക്കുന്നു. ഒരേ നെറ്റ്വർക്കിൽ ആയിരിക്കുന്നത് ഡൊമെയിൻ പൂർവ്വപദം സൂചിതമാണെന്ന് തെളിയിക്കുന്നില്ല. ഡൊമെയിൻ-യോഗ്യ നാമം യാന്ത്രികമായി വേറെ പ്രാമാണീകരണ പ്രോട്ടോക്കോളും അല്ല.
URL എസ്കേപ്പിംഗ് ഉദ്ദേശിച്ച അക്കൗണ്ട് സംരക്ഷിക്കണം, അത് മാറ്റരുത്. സ്രോതസ്സ് ഭാഷയിലെ സ്ട്രിംഗിലുള്ള ബാക്ക്സ്ലാഷ്, അക്കൗണ്ട് നാമത്തിലുള്ള ബാക്ക്സ്ലാഷ്, URI-യ്ക്കുള്ളിലെ അതിന്റെ ശതമാന-എൻകോഡഡ് രൂപം എന്നിവ വേറിട്ട പാളികളാണ്.
ഓപ്പറേറ്ററിൽ നിന്ന് സ്വീകാര്യമായ ഐഡന്റിറ്റി രൂപവും സ്കീമും വാങ്ങി, തുടർന്ന് അനുയോജ്യമായ ക്രെഡൻഷ്യൽ ഇന്റർഫേസ് ഉപയോഗിക്കുക. ചെറിയ നാമം, ഡൊമെയിൻ നാമം, ഇമെയിൽ പോലെയുള്ള നാമം എന്നിവയ്ക്കിടയിൽ ക്രമരഹിതമായി മാറുന്നത് യഥാർത്ഥ 407-നെക്കുറിച്ച് ദുർബലമായ തെളിവ് സൃഷ്ടിക്കുന്നു.