APM പോർട്ടൽ ആക്സസ്: ആപ്ലിക്കേഷൻ സെഷൻ ആരുടേതാണ്?
BIG-IP Portal Access പ്രസിദ്ധീകരണ തീരുമാനത്തിനായി അഞ്ച് പരിശോധനകൾ: റിസോഴ്സ് പരിധി, ബാക്കെൻഡ് സെഷൻ, രണ്ട് ടൈമർ, ലോഗൗട്ടിന്റെ അർത്ഥം, റീറൈറ്റിംഗിന്റെ പരിധികൾ.
BIG-IP APM Portal Access വഴി ഇന്ട്രാനെറ്റ് ആപ്ലിക്കേഷൻ പ്രസിദ്ധീകരിക്കുന്നത് സെഷനുകളെക്കുറിച്ചുള്ള തീരുമാനമാണ്, വെർച്വൽ സർവറിന്റെ പകർപ്പല്ല. പോർട്ടൽ ഉപയോക്താവിനെ അകത്തേക്ക് വിടുന്നു, റീറൈറ്റ് പ്രൊഫൈൽ തിരഞ്ഞെടുത്ത അഭ്യർത്ഥനകളെ ഗേറ്റ്വേ പാതയിൽ നിലനിർത്തുന്നു, ആപ്ലിക്കേഷന് ഇപ്പോഴും സ്വന്തം സെഷൻ ഉണ്ട്. അഞ്ച് പരിശോധനകൾ പ്രവചനാതീതമായി പ്രവർത്തിക്കുന്ന രൂപകൽപ്പനയെ, ഹെൽപ്പ് ഡെസ്ക് ഓരോ ഉപയോക്താവിൽ നിന്നും ടൈംഔട്ടുകൾ അറിയുന്ന രൂപകൽപ്പനയിൽ നിന്ന് വേർതിരിക്കുന്നു. അവ ക്രമത്തിൽ ചെയ്ത് ശരിയല്ലാത്ത ആദ്യ പരിശോധനയിൽ നിർത്തുക.
പരിശോധന 1: റിസോഴ്സ് പ്രസിദ്ധീകരിച്ചതാണ്, വെറും ലിങ്ക് ചെയ്തതല്ല
webtop-ലെ ബുക്ക്മാർക്ക് ഉപയോക്താവ് ഒരു എൻട്രി കാണുന്നു എന്ന് തെളിയിക്കുന്നു. ആപ്ലിക്കേഷൻ പ്രസിദ്ധീകരിച്ചു എന്ന് തെളിയിക്കുന്നില്ല. ആക്സസ് പ്രൊഫൈൽ, റീറൈറ്റ് പ്രൊഫൈൽ, അവയെ സംയോജിപ്പിക്കുന്ന വെർച്വൽ സർവർ എന്നിവ കണ്ടെത്തി, റിസോഴ്സ് അനുവദനം നിങ്ങൾ കരുതുന്ന ആപ്ലിക്കേഷനിലേക്കാണോ എന്ന് ഉറപ്പാക്കുക. ഈ മൂന്നിൽ ഏതെങ്കിലും ഇല്ലെങ്കിലോ പൊരുത്തക്കേടുണ്ടെങ്കിലോ ബാക്കി പട്ടിക അർത്ഥശൂന്യമാണ്.
പകുതി പ്രസിദ്ധീകരിച്ച അവസ്ഥ പ്രവേശന കേന്ദ്രത്തിൽ ആരോഗ്യകരമായി കാണപ്പെടുന്നു. വെർച്വൽ സർവർ ആക്സസ് പ്രൊഫൈൽ വഹിക്കുമ്പോൾ റീറൈറ്റ് പ്രൊഫൈൽ മറ്റൊരു റിസോഴ്സ് URI-യിലേക്ക് പരിമിതപ്പെടുത്തിയിരിക്കുന്നു, അതിനാൽ webtop എൻട്രി പ്രത്യക്ഷപ്പെടുകയും ആദ്യ പേജ് ലോഡ് ചെയ്യുകയും ചെയ്യുന്നു, പിന്നീട് ഉപപാത അഭ്യർത്ഥനകൾ ഗേറ്റ്വേ പാത വിട്ട് നേരിട്ട് ബാക്കെൻഡിലെത്തുന്നു. വിപരീത ചിത്രം തെറ്റായ ആപ്ലിക്കേഷന് നൽകിയ റിസോഴ്സാണ്: ബുക്ക്മാർക്ക് തുറക്കുന്നു, ആരും അനുവദിക്കാത്ത എന്തോ തുറക്കുന്നു.
പരിശോധന 2: ബാക്കെൻഡ് സെഷൻ വേറിട്ട അവസ്ഥയാണ്
APM ഉപയോക്താവിനെ സൈൻ ഇൻ ചെയ്തതായി കണക്കാക്കുമ്പോഴും ബാക്കെൻഡിന് സ്വന്തം പ്രാമാണീകരണം ആവശ്യമായേക്കാം. പിന്തുണയ്ക്കുന്ന SSO സംയോജനം ആ ബന്ധം നിങ്ങൾക്കായി സ്ഥാപിക്കുന്നു, പക്ഷേ പോർട്ടൽ ലോഗിൻ സ്വീകരിക്കുന്നത് ഓരോ ആപ്ലിക്കേഷനും ഒരേ ക്രെഡൻഷ്യലുകളോ ഒരേ സെഷൻ കുക്കിയോ സ്വീകരിക്കുമെന്ന് അർത്ഥമാക്കുന്നില്ല. റിസോഴ്സിന് SSO കോൺഫിഗർ ചെയ്തിട്ടില്ലെങ്കിൽ, ആപ്ലിക്കേഷൻ ഇതിനകം പ്രാമാണീകരിച്ച പോർട്ടലിനുള്ളിൽ സ്വന്തം ലോഗിൻ ആവശ്യപ്പെടും.
കാണാവുന്ന പ്രോംപ്റ്റ് മാറ്റാൻ SSO നിർജീവമാക്കുന്നത് സാധാരണവും മോശവുമായ ഒരു ചുരുക്കവഴിയാണ്: പ്രോംപ്റ്റ് സൃഷ്ടിച്ച ജീവിതചക്രത്തെ തൊട്ടുപോകാതെ പ്രാമാണീകരണ രൂപകൽപ്പന മാറ്റുന്നു. പകരം ബാക്കെൻഡ് ലോഗിൻ ഒട്ടും കാണേണ്ടതുണ്ടോ എന്ന് തീരുമാനിക്കുക, കാണേണ്ടതുണ്ടെങ്കിൽ അതിനെ പ്രസിദ്ധീകരിച്ച ഫ്ലോയുടെ വ്യക്തമായ ഭാഗമാക്കുക.
പരിശോധന 3: രണ്ട് ഘടികാരങ്ങളുണ്ട്, അവ ഒരേ ഘടികാരമല്ല
APM-ന്റെ ആക്സസ് പ്രൊഫൈലിന് നിഷ്ക്രിയതാ ടൈംഔട്ടും സെഷന്റെ പരമാവധി ആയുസ്സും ഉണ്ട്. ആപ്ലിക്കേഷന് സ്വന്തം ഐഡിൾ ടൈമറും കുക്കി കാലഹരണവും ഉണ്ട്. പോർട്ടൽ ടൈമർ കൂട്ടുന്നത് ആപ്ലിക്കേഷൻ സെഷൻ നീട്ടുന്നില്ല, ആപ്ലിക്കേഷൻ സെഷൻ ചുരുക്കുന്നത് ഉപയോക്താവിനെ പോർട്ടലിൽ നിന്ന് ലോഗ് ഔട്ട് ചെയ്യുന്നുമില്ല.
| Timer | Owner | What it ends |
|---|---|---|
| Inactivity timeout | APM access profile | the portal session after idle time |
| Maximum lifetime | APM access profile | the portal session regardless of activity |
| Application cookie | Backend application | the application session inside a live portal |
ക്ലാസിക് സപ്പോർട്ട് കോൾ പൊരുത്തപ്പെടാത്ത ഒരു ജോടിയിൽ നിന്ന് ഉണ്ടാകുന്നു: പോർട്ടൽ ഇപ്പോഴും സാധുവാണ്, ആപ്ലിക്കേഷൻ സെഷൻ അല്ല, ഉപയോക്താവ് പോർട്ടലിന് വിരുദ്ധമെന്ന് തോന്നുന്ന ലോഗിൻ ഫോം കാണുന്നു. അത് ശരിയായ പെരുമാറ്റമാണ്, തകരാറല്ല, പരിഹാരം ഈ ആപ്ലിക്കേഷനായി ഏത് ഘടികാരം ആദ്യം കാലഹരണപ്പെടണം എന്ന് തിരഞ്ഞെടുക്കുകയാണ്.
പരിശോധന 4: ലോഗൗട്ടിന് നിർവചിച്ച പരിധിയുണ്ട്
ആപ്ലിക്കേഷന്റെ സൈൻ-ഔട്ട് ബട്ടൺ എന്ത് അവസാനിപ്പിക്കണം എന്ന് എഴുതുക: ആ ആപ്ലിക്കേഷൻ മാത്രം, മുഴുവൻ APM സെഷൻ, അതോ ഐഡന്റിറ്റി പ്രൊവൈഡറിന്റെ വിശാലമായ സെഷൻ. ആക്സസ് പ്രൊഫൈൽ ഓപ്ഷണൽ കാലതാമസത്തോടെ ലോഗൗട്ട് URI പട്ടിക പിന്തുണയ്ക്കുന്നു, ആവശ്യകത അതാണെങ്കിൽ ആപ്ലിക്കേഷൻ ലോഗൗട്ട് പോർട്ടൽ സെഷൻ അവസാനിപ്പിക്കുന്നത് ഇപ്രകാരമാണ്. അതില്ലാതെ, ആപ്ലിക്കേഷൻ ലോഗൗട്ട് പോർട്ടലിനെ ജീവനോടെ വിടുന്നു, അടുത്ത അഭ്യർത്ഥന ഉപയോക്താവിനെ നിശ്ശബ്ദമായി വീണ്ടും സൈൻ ഇൻ ചെയ്തേക്കാം.
അതേ പോർട്ടലിലെ മറ്റ് റിസോഴ്സുകളിലുള്ള പ്രഭാവം കണക്കാക്കുക. ഒരു ആപ്ലിക്കേഷനിൽ നിന്നുള്ള ലോഗൗട്ട് ആറ് മറ്റുള്ളവയുടെ സെഷൻ അവസാനിപ്പിക്കുന്നുവെങ്കിൽ, പെരുമാറ്റം മുൻകൂട്ടി ആപ്ലിക്കേഷൻ ഉടമയുമായി യോജിച്ചിട്ടില്ലെങ്കിൽ ഉപയോക്താക്കൾ അതിനെ ബഗ് എന്ന് വിളിക്കും. ടാബ് അടച്ച് webtop-ലേക്ക് മടങ്ങുന്നത് എന്തെങ്കിലും അവസാനിച്ചതിന്റെ തെളിവല്ല.
പരിശോധന 5: ആപ്ലിക്കേഷൻ റീറൈറ്റിംഗിനെ അതിജീവിക്കുന്നു
Portal Access തിരഞ്ഞെടുത്ത വെബ് ഉള്ളടക്കം മാറ്റിയെഴുതുന്നു, റീറൈറ്റിംഗിന് അതിരുകളുണ്ട്. ആധുനിക ക്ലയന്റ്-സൈഡ് സവിശേഷതകൾ, ബാക്ക്ഗ്രൗണ്ട് വർക്കർമാർ, അപ്ലോഡ് ഫ്ലോകൾ, ഫെഡറേറ്റഡ് ലോഗിൻ എന്നിവ ഒരു നിർദ്ദിഷ്ട റിലീസ് കൈകാര്യം ചെയ്യുന്നതിന് പുറത്തായേക്കാം. F5-ന്റെ പതിപ്പ് അടിസ്ഥാനമാക്കിയുള്ള അനുയോജ്യതാ മാട്രിക്സ് പ്രതിജ്ഞാബദ്ധതയ്ക്ക് മുമ്പ് വായിക്കേണ്ട രേഖയാണ്, കാരണം പരിധികൾ റിലീസിനെ ആശ്രയിച്ചിരിക്കുന്നു.
ലാൻഡിംഗ് പേജല്ല, പ്രധാന ഫ്ലോകൾ പരീക്ഷിക്കുക: സൈൻ ഇൻ ചെയ്യുക, ഓരോ ആവശ്യമായ ഫംഗ്ഷനിലൂടെയും നീങ്ങുക, ആപ്ലിക്കേഷൻ അപ്ലോഡ് ചെയ്യുന്നുവെങ്കിൽ അപ്ലോഡ് ചെയ്യുക, ഉദ്ദേശിച്ച സെഷൻ കാലഹരണപ്പെടാൻ അനുവദിക്കുക, ഓരോ ലോഗൗട്ട് പാതയും പിന്തുടരുക. ഒരിക്കൽ റെൻഡർ ചെയ്യുന്ന പേജ് ആപ്ലിക്കേഷൻ പ്രവർത്തിക്കുന്നു എന്നതിന്റെ തെളിവല്ല.
ആവശ്യമായ ഫ്ലോ മാറ്റിയെഴുതാൻ കഴിയാത്തപ്പോൾ, രേഖപ്പെടുത്തിയ ഫെഡറേഷൻ, റിവേഴ്സ് പ്രോക്സി അല്ലെങ്കിൽ നെറ്റ്വർക്ക് ആക്സസ് രൂപകൽപ്പനയിലേക്ക് പോകുക. പൊതുവായ ടണൽ പോലെ പെരുമാറാൻ ആവശ്യപ്പെടുന്ന ബ്രൗസർ പോർട്ടൽ ഡെമോ പാസാകും, ഓഡിറ്റിൽ പരാജയപ്പെടും.