ഒരു വരി കോഡ് നിങ്ങളുടെ മുഴുവൻ ആക്സസ് കൺട്രോൾ മോഡലിനെയും തകിടം മറിച്ചേക്കാം. റിക്വസ്റ്റ് ബോഡി (request body) നേരിട്ട് ഒരു ഡാറ്റാബേസ് അപ്‌ഡേറ്റിലേക്ക് നൽകിയാൽ, നിങ്ങളുടെ സ്കീമ (schema) മാറ്റാൻ ക്ലയന്റിന് ഒരു പേന കൈമാറുന്നതിന് തുല്യമാണിത്. ഇതിനെയാണ് മാസ് അസൈൻമെന്റ് (mass assignment) എന്ന് വിളിക്കുന്നത്. ഇതൊരു അപൂർവ്വമായ ബഗ്ഗല്ല. ഒരു API അതിന്റെ പേലോഡിനെ (payload) സ്വന്തം അപ്‌ഡേറ്റ് പോളിസിയായി കണക്കാക്കുമ്പോൾ സംഭവിക്കുന്ന ഒരു ഡിസൈൻ പരാജയമാണിത്.

await db.users.update(req.params.id, { ...req.body });

ഇത് കാണാൻ വൃത്തിയുള്ളതാണ്, ടൈപ്പിംഗ് സമയം ലാഭിക്കുകയും ചെയ്യുന്നു. എന്നാൽ ഇതിലെ കീകൾ (keys) നിയന്ത്രിക്കുന്നത് ക്ലയന്റാണ്. ഒരു സാധാരണ പ്രൊഫൈൽ അപ്‌ഡേറ്റിൽ തന്നെ അറ്റാക്കർക്ക് "role": "admin", "accountId": "someone_else", അല്ലെങ്കിൽ "credit": 99999" എന്നിങ്ങനെയുള്ളവ ചേർക്കാൻ സാധിക്കും. നിങ്ങളുടെ വാലിഡേഷൻ ലെയർ ഈ മൂല്യങ്ങൾ സ്ട്രിംഗുകളോ നമ്പറുകളോ ആണോ എന്ന് പരിശോധിക്കുകയും അവ ശരിയാണെന്ന് പറയുകയും ചെയ്തേക്കാം. എന്നാൽ വാലിഡിറ്റി (validity) എന്നത് അതൊറൈസേഷൻ (authorization) അല്ല. ഒരു ഉപയോക്താവിന് ആ റെക്കോർഡിന്മേൽ നിയമാനുസൃതമായ അവകാശം ഉണ്ടായിരിക്കാം. എന്നാൽ അതിനുള്ളിലെ എല്ലാ ഫീൽഡുകളും എഡിറ്റ് ചെയ്യാൻ അവർക്ക് അവകാശമുണ്ടെന്ന് ഇതിനർത്ഥമില്ല.

മാസ് അസൈൻമെന്റ് യഥാർത്ഥത്തിൽ എങ്ങനെയാണ് കാണപ്പെടുന്നത്

സൗകര്യങ്ങളിൽ ആണ് അപകടം ഒളിഞ്ഞിരിക്കുന്നത്. ഫ്രെയിംവർക്കുകളും ORM-കളും JSON കീകളെ നേരിട്ട് ഡാറ്റാബേസ് കോളങ്ങളുമായി മാപ്പ് ചെയ്യാൻ എളുപ്പമാക്കുന്നു. നിങ്ങൾ ഇത് ചെയ്യുമ്പോൾ, എന്തൊക്കെ മാറണം എന്നതിനെക്കുറിച്ച് ഡാറ്റാബേസിനോട് ക്ലയന്റിനെ വിശ്വസിക്കാൻ നിങ്ങൾ ആവശ്യപ്പെടുകയാണ് ചെയ്യുന്നത്.

പ്രൊഫൈൽ അപ്‌ഡേറ്റ് ചെയ്യുന്ന ഒരു ഉപയോക്താവ് displayName, bio എന്നിവയ്ക്ക് ശരിയായ ഡാറ്റ അയച്ചേക്കാം, എന്നാൽ അതോടൊപ്പം role അല്ലെങ്കിൽ balance എന്നിവയും ഉൾപ്പെടുത്തിയേക്കാം. നിങ്ങളുടെ കൺട്രോളർ ആ ഒബ്‌ജക്റ്റിനെ നേരിട്ട് ഫോർവേഡ് ചെയ്യുകയാണെങ്കിൽ, ഡാറ്റാബേസ് എല്ലാം എഴുതിച്ചേക്കാം. വാലിഡേഷൻ തെറ്റായ മൂല്യങ്ങളെ പിടികൂടും, എന്നാൽ ദുരുപയോഗം ചെയ്യുന്ന കീകളെ (malicious keys) അത് അപൂർവ്വമായി മാത്രമേ പിടികൂടൂ. "ഈ ഉപയോക്താവിന് അവരുടെ പ്രൊഫൈൽ അപ്‌ഡേറ്റ് ചെയ്യാൻ അനുവാദമുണ്ട്" എന്ന ബിസിനസ് റൂൾ, ആ വരിയിലെ (row) എല്ലാ കോളങ്ങൾക്കും നൽകുന്ന ഒരു പൊതു അനുമതിയായി മാറുന്നു.

ഇതിനുള്ള പരിഹാരം കൂടുതൽ വാലിഡേഷൻ നൽകലല്ല, മറിച്ച് കൂടുതൽ കർശനമായ ആർക്കിടെക്ചർ ആണ്.

മൂന്ന് കവാടങ്ങൾ (The Three Gates)

സുരക്ഷിതമായ ഒരു മ്യൂട്ടേഷൻ (mutation) സ്റ്റോറേജിൽ എത്തുന്നതിന് മുമ്പ് മൂന്ന് വ്യത്യസ്ത പരിശോധനകളിലൂടെ കടന്നുപോകണം.

അംഗീകരിക്കപ്പെട്ട ഫീൽഡുകൾ (Allowlist)

ഏതെല്ലാം കീകൾ നിങ്ങൾ പരിശോധിക്കണം എന്ന് കൃത്യമായി തീരുമാനിച്ചുകൊണ്ട് തുടങ്ങുക. ഒരു ഫീൽഡ് അലൗലിസ്റ്റിൽ (allowlist) ഇല്ലെങ്കിൽ, ആ റിക്വസ്റ്റ് നിരസിക്കുകയോ ആ കീ ഒഴിവാക്കുകയോ ചെയ്യുക. ഇത് ഡിഫോൾട്ട് രീതിയെ മാറ്റുന്നു: ഒരു ഡെവലപ്പർ വ്യക്തമായി അനുവദിക്കുന്നത് വരെ പുതിയ ഡാറ്റാബേസ് കോളങ്ങൾ എഴുതാൻ പാടില്ലാത്തവയായി (non-writable) മാറും. കാലക്രമേണ സ്കീമകൾ വളരും. ഒരു സഹപ്രവർത്തകൻ stripeCustomerId, departmentBudget, അല്ലെങ്കിൽ isVerified ഫ്ലാഗ് എന്നിവ ചേർക്കുന്നു എന്ന് കരുതുക. അലൗലിസ്റ്റ് ഉപയോഗിക്കുന്നതിലൂടെ, ഈ പുതിയ കോളങ്ങൾ ക്ലയന്റ് എഴുത്തുകളിൽ നിന്ന് സ്വയമേവ സംരക്ഷിക്കപ്പെടുന്നു. അലൗലിസ്റ്റ് ഇല്ലെങ്കിൽ, ഓരോ പുതിയ കോളവും അബദ്ധവശാൽ ഒരു API സർഫസ് ആയി മാറുന്നു.

ശരിയായ മൂല്യങ്ങൾ (Valid Values)

ഏതെല്ലാം ഫീൽഡുകളാണ് അനുവദനീയമെന്ന് അറിഞ്ഞുകഴിഞ്ഞാൽ, ആ മൂല്യങ്ങൾ യുക്തിസഹമാണോ എന്ന് പരിശോധിക്കുക. ടൈംസോൺ സ്ട്രിംഗ് ശരിയായ ടൈംസോൺ ആണോ? ഇമെയിൽ ഫോർമാറ്റ് ശരിയാണോ? നമ്പർ കൃത്യമായ പരിധിക്കുള്ളിലാണോ? ഇത് ഒരു ശുചിത്വ നടപടിയാണ് (hygiene). ഇത് നിങ്ങളുടെ സിസ്റ്റത്തിലേക്ക് തെറ്റായ വിവരങ്ങൾ വരുന്നത് തടയുന്നു, എന്നാൽ ദുരുപയോഗം തടയുന്നില്ല. തെറ്റായ വ്യക്തി role ഫീൽഡിൽ ഒരു ശരിയായ "admin" സ്ട്രിംഗ് അയച്ചാൽ പോലും അത് അപകടകരമാണ്.

അധികാരപ്പെട്ട മാറ്റങ്ങൾ (Authorized Transitions)

മിക്ക ടീമുകളും ഒഴിവാക്കുന്ന കവാടമാണിത്, യഥാർത്ഥ സംരക്ഷണം ഇരിക്കുന്നത് ഇവിടെയാണ്. വളരെ സൂക്ഷ്മമായ ഒരു ചോദ്യം ചോദിക്കുക: ഈ പ്രത്യേക ആക്റ്റർക്ക് (actor) ഈ പ്രത്യേക റെക്കോർഡിലെ ഈ പ്രത്യേക ഫീൽഡ് മാറ്റാൻ അനുമതിയുണ്ടോ? "ഉപയോക്താവ് ഒരു അഡ്മിൻ ആണോ?" എന്നല്ല, "ഉപയോക്താവിന് write:users സ്കോപ്പ് ഉണ്ടോ?" എന്നല്ല. മറിച്ച്, "ഈ ഉപയോക്താവിന് അവരുടെ സ്വന്തം displayName മാറ്റാൻ അനുവാദമുണ്ടോ, എന്നാൽ ഒരിക്കലും അവരുടെ accountId മാറ്റാൻ പാടില്ലാത്തതാണോ?" എന്നാണ് ചോദിക്കേണ്ടത്. ഫീൽഡ് അടിസ്ഥാനമാക്കിയുള്ള അതൊറൈസേഷൻ (Per-field authorization) വഴി "Editor" അല്ലെങ്കിൽ "User" പോലുള്ള വിപുലമായ അനുമതികൾ വരിയിലെ ഓരോ പ്രോപ്പർട്ടിക്കും മാസ്റ്റർ കീ ആയി മാറുന്നത് തടയാം.

പാച്ച് ഫംഗ്ഷൻ നിർമ്മിക്കുക (Building the Patch Function)

ഈ മൂന്ന് കവാടങ്ങളെ ഒരു സിംഗിൾ പൈപ്പ്‌ലൈനായി (pipeline) ബന്ധിപ്പിക്കുക. ഒരു പാച്ച് റിക്വസ്റ്റ് വരുമ്പോൾ, അത് ക്രമമായി ഓരോ ഘട്ടങ്ങളിലൂടെയും കടത്തിവിടുക.

ഒന്നാമതായി, നിങ്ങളുടെ അലൗലിസ്റ്റിന് അനുസൃതമായി ഇൻപുട്ട് ഫിൽട്ടർ ചെയ്യുക. ഈ എൻഡ്‌പോയിന്റിന് role അനുവദനീയമായ ഒരു ഫീൽഡ് അല്ലെങ്കിൽ, അവിടെത്തന്നെ നിർത്തുക. നിങ്ങൾക്ക് ഒരിക്കലും ലഭിക്കേണ്ടതില്ലാത്ത ഒരു മൂല്യത്തെ വാലിഡേറ്റ് ചെയ്യാനോ അതൊറൈസ് ചെയ്യാനോ ഉള്ള കാര്യമില്ല.

രണ്ടാമതായി, അനുവദനീയമായ മൂല്യങ്ങൾ വാലിഡേറ്റ് ചെയ്യുക. ടൈപ്പുകൾ (types), ഫോർമാറ്റുകൾ, ബിസിനസ് റൂളുകൾ എന്നിവ പരിശോധിക്കുക. ഒരു ലൊക്കേഷൻ ഫീൽഡ് ശരിയായ ടൈംസോണിലേക്ക് വിവർത്തനം ചെയ്യാവുന്ന ഒരു സ്ട്രിംഗ് ആയിരിക്കണം. ഒരു അവതാർ URL നിശ്ചിത ദൈർഘ്യമുള്ള ഒരു സാധുവായ URI ആയിരിക്കണം.

മൂന്നാമതായി, ആക്ഷൻ അതൊറൈസ് ചെയ്യുക. ആക്റ്റർ ആ റെക്കോഡിന്റെ ഉടമയാണോ, അല്ലെങ്കിൽ ഈ ഫീൽഡിന് ആവശ്യമായ കൃത്യമായ അനുമതി അയാൾക്കുണ്ടോ എന്ന് പരിശോധിക്കുക. വ്യക്തിഗത വിവരങ്ങൾക്ക് ഉടമസ്ഥാവകാശം (ownership) ഒരു നല്ല ഡിഫോൾട്ട് ആണ്, എന്നാൽ ചില ഫീൽഡുകൾക്ക് അധിക കവാടങ്ങൾ ആവശ്യമാണ്. ഒരു ഉപയോക്താവിന് അവരുടെ പ്രൊഫൈലിന്മേൽ ഉടമസ്ഥാവകാശം ഉണ്ടായിരിക്കാം, എങ്കിലും ഒരു ബില്ലിംഗ് അഡ്മിന് മാത്രമേ taxRegion മാറ്റാൻ അനുവാദമുള്ളൂ.

നാലാമതായി, ഡാറ്റ നോർമലൈസ് (normalize) ചെയ്യുക. വൈറ്റ് സ്പേസുകൾ ഒഴിവാക്കുക, ആവർത്തിച്ചുള്ള സ്പേസുകൾ കുറയ്ക്കുക, ഇമെയിലുകൾ ലോവർകേസ് ആക്കുക, അല്ലെങ്കിൽ കൺട്രോൾ ക്യാരക്ടറുകൾ നീക്കം ചെയ്യുക. വാലിഡേഷന് ശേഷം എന്നാൽ സ്റ്റോറേജിന് മുമ്പ് ഇത് ചെയ്യുക, അങ്ങനെ അതൊറൈസേഷൻ പരിശോധനകളിൽ അശുദ്ധമായ സ്ട്രിംഗുകൾ (dirty strings) താരതമ്യം ചെയ്യുന്നത് ഒഴിവാക്കാം.

ഇൻപുട്ട് ഏതെങ്കിലും പരിശോധനയിൽ (gate) പരാജയപ്പെട്ടാൽ, ആ മ്യൂട്ടേഷൻ (mutation) മുഴുവനായി നിരസിക്കുക. സുരക്ഷിതമായ ഫീൽഡുകൾ മാത്രം ഭാഗികമായി സ്വീകരിക്കുകയും തെറ്റായവ നിശബ്ദമായി ഒഴിവാക്കുകയും ചെയ്യരുത്. ഒരു മിശ്രിത പ്രതികരണം (mixed response) നൽകുന്നത്, ക്ലയന്റുകൾ തങ്ങൾക്ക് അറിയാവുന്ന എല്ലാ കീകളും പരീക്ഷിച്ചു നോക്കി ഏതാണ് പ്രവർത്തിക്കുന്നത് എന്ന് കണ്ടെത്താൻ പ്രേരിപ്പിക്കും. പരാജയം വ്യക്തമായി അറിയിക്കുക.

യഥാർത്ഥത്തിൽ ശ്രദ്ധിക്കേണ്ട എഡ്ജ് കേസുകൾ (Edge Cases)

മാസ് അസൈൻമെന്റ് പ്രതിരോധങ്ങൾ (Mass assignment defenses) നിലനിൽക്കുന്നത് യൂണിറ്റ് ടെസ്റ്റുകൾ പലപ്പോഴും ശ്രദ്ധിക്കാതെ പോകുന്ന സൂക്ഷ്മമായ കാര്യങ്ങളിലാണ്.

ഡ്യൂപ്ലിക്കേറ്റ് JSON കീകൾ (Duplicate JSON keys). അറ്റാക്കർമാർക്ക് {"role": "user", "role": "admin"} പോലുള്ള പേലോഡുകൾ അയക്കാൻ കഴിയും. നിങ്ങളുടെ HTTP പാഴ്സറെയും (parser) ഫ്രെയിംവർക്കിനെയും ആശ്രയിച്ച്, നിങ്ങളുടെ ആപ്ലിക്കേഷൻ കോഡ് ഒബ്ജക്റ്റ് കാണുന്നതിന് മുമ്പ് രണ്ടാമത്തെ മൂല്യം ആദ്യത്തേതിനെ മറികടന്നേക്കാം (overwrite). പാഴ്സർ തലത്തിൽ തന്നെ ഈ പെരുമാറ്റം പരിശോധിക്കുക. നിങ്ങളുടെ ഫ്രെയിംവർക്ക് അവസാനത്തെ കീ നിശബ്ദമായി സ്വീകരിക്കുന്നതാണെങ്കിൽ, നിങ്ങളുടെ അലൗലിസ്റ്റ് (allowlist) "user" എന്ന് കാണിക്കുമ്പോൾ ഡാറ്റാബേസ് "admin" സ്വീകരിച്ചേക്കാം.

നെസ്റ്റഡ് ഒബ്ജക്റ്റുകൾ, നൾസ് (nulls), അറേകൾ (arrays). പേലോഡ് ഒരു ഫ്ലാറ്റ് (flat) ഘടനയാണെന്ന് കരുതരുത്. ഒരു ക്ലയന്റ് നിയന്ത്രിത ഫീൽഡിനെ { "profile": { "role": "admin" } } എന്നതുപോലെ ഒരു നെസ്റ്റഡ് ഒബ്ജക്റ്റിനുള്ളിൽ ഉൾപ്പെടുത്തിയേക്കാം. നിങ്ങളുടെ സ്കീമിൽ (schema) റിക്കർഷൻ (recursion) ഉണ്ടെങ്കിൽ അലൗലിസ്റ്റിലും അത് ഉണ്ടായിരിക്കണം. അതുപോലെ തന്നെ, null എങ്ങനെ കൈകാര്യം ചെയ്യണമെന്ന് തീരുമാനിക്കുക. "ഈ ഫീൽഡ് അവഗണിക്കുക" എന്നാണോ അതോ "ഈ ഫീൽഡ് ഡിലീറ്റ് ചെയ്യുക" എന്നാണോ അതിന്റെ അർത്ഥം? കൂടാതെ ഒരു അറേ ആണ് പ്രതീക്ഷിക്കുന്നതെങ്കിൽ, നിങ്ങളുടെ വാലിഡേറ്റർ അപ്രതീക്ഷിത ഘടനകളെ നിരസിക്കുന്നുണ്ടോ, അതോ ഒരു ഒബ്ജക്റ്റിനെ അറേയാക്കി മാറ്റി അനുവദിക്കുന്നുണ്ടോ എന്ന് ഉറപ്പുവരുത്തുക.

യൂണിക്കോഡ് നോർമലൈസേഷൻ (Unicode normalization). രണ്ട് സ്ട്രിംഗുകൾ മനുഷ്യർക്ക് ഒരേപോലെ തോന്നാമെങ്കിലും അവ ബൈറ്റുകളുടെ വ്യത്യസ്ത ക്രമങ്ങളാകാം. ഒരു ഉപയോക്താവ് ഒരു പ്രീകോമ്പോസ്ഡ് (precomposed) é അല്ലെങ്കിൽ ഒരു ഡീകമ്പോസ്ഡ് (decomposed) e കൂടാതെ കോമ്പിനിംഗ് ആക്സന്റ് എന്നിവ അയച്ചേക്കാം. നിങ്ങളുടെ ഓതറൈസേഷൻ ചെക്ക് (authorization check) ഒരു രീതിയിലും സ്റ്റോറേജ് ലെയർ മറ്റൊരു രീതിയിലും നോർമലൈസ് ചെയ്യുന്നുണ്ടെങ്കിൽ, അത് ഡാറ്റയിലെ പൊരുത്തക്കേടുകൾക്കോ അല്ലെങ്കിൽ യൂസർനെയിം കൊളിഷൻ (username collision) വഴി ലോജിക് ബൈപാസ് ചെയ്യപ്പെടുന്നതിനോ കാരണമാകും. നേരത്തെ തന്നെ നോർമലൈസ് ചെയ്യുക, അത് കൃത്യമായ രീതിയിൽ തുടർച്ചയായി ചെയ്യുക.

റേസ് കണ്ടീഷനുകൾ (Race conditions). ഓതറൈസേഷൻ തീരുമാനങ്ങൾ നിശ്ചലമായ ഒന്നല്ല. അവ ഒരു നിശ്ചിത സമയത്ത് സംഭവിക്കുന്നവയാണ്. രണ്ട് റിക്വസ്റ്റുകൾക്ക് ഒരേ റെക്കോർഡ് വായിക്കാൻ കഴിയും, രണ്ടും ആ ആക്റ്റർക്ക് (actor) എഴുതാൻ അനുവാദമുണ്ടെന്ന് കാണിച്ചേക്കാം, തുടർന്ന് രണ്ടും അപ്ഡേറ്റുകൾ നൽകിയേക്കാം. ഇതിനിടയിൽ സ്റ്റേറ്റ് (state) അല്ലെങ്കിൽ ആക്റ്ററുടെ പെർമിഷനുകൾ മാറിയേക്കാം. എപ്പോഴും ഒരു വേർഷൻ നമ്പർ (version number) അല്ലെങ്കിൽ സ്റ്റേറ്റ് മെഷീൻ വാല്യൂ (state machine value) ഉപയോഗിച്ച് ഡാറ്റാബേസ് അപ്ഡേറ്റുകൾ നടത്തുക. UPDATE users SET ... WHERE id = ? AND version = 5 എന്നതുപോലെയുള്ള രീതി ഉപയോഗിക്കുക. നിങ്ങൾ വായിച്ചതിന് ശേഷം ആ റോ (row) മാറിയിട്ടുണ്ടെങ്കിൽ, അപ്ഡേറ്റ് പരാജയപ്പെടും. പരാജയം സംഭവിക്കുമ്പോൾ അത് വീണ്ടും ശ്രമിക്കുകയോ (retry) നിരസിക്കുകയോ ചെയ്യുക. ഇത് പഴയ ഓതറൈസേഷൻ ചെക്കുകൾ നിങ്ങളുടെ ഡാറ്റ നശിപ്പിക്കുന്നത് തടയും.

പ്രധാനപ്പെട്ട കാര്യങ്ങൾ നിരീക്ഷിക്കുക

നിങ്ങൾക്ക് കാണാൻ കഴിയാത്ത ഒന്നിനെ സുരക്ഷിതമാക്കാൻ കഴിയില്ല. ഓഡിറ്റ് ലോഗിംഗ് (audit logging) വെറുമൊരു ആക്ഷന് (action) ചുറ്റും മാത്രമല്ല, തീരുമാനത്തിന് (decision) ചുറ്റും നിർമ്മിക്കുക.

ആക്റ്റർ ഐഡിയും (actor ID) ടാർഗെറ്റ് ഐഡിയും (target ID) ലോഗ് ചെയ്യുക. സ്വീകരിച്ച ഫീൽഡ് പേരുകളും നിരസിച്ചവയും കൃത്യമായി രേഖപ്പെടുത്തുക. തീരുമാനം എടുത്ത പോളിസി വേർഷനും (policy version) അതിന്റെ ഫലവും ലോഗ് ചെയ്യുക. ഒരു ഉപയോക്താവിന്റെ പ്രൊഫൈൽ അപ്ഡേറ്റ് ചെയ്യുമ്പോൾ role നിരസിക്കപ്പെടാൻ തുടങ്ങുകയാണെങ്കിൽ, അത് ഉടൻ തന്നെ നിങ്ങൾക്ക് അറിയാൻ സാധിക്കണം.

ബിയറർ ടോക്കണുകൾ (bearer tokens) ഒരിക്കലും ലോഗ് ചെയ്യരുത്. റിക്വസ്റ്റ് ബോഡികൾ (request bodies) മുഴുവനായി ലോഗുകളിൽ ഇടരുത്. ഒരു ഓഡിറ്റ് ട്രയൽ (audit trail) ദുരുപയോഗം അന്വേഷിക്കാൻ നിങ്ങളെ സഹായിക്കണം, അല്ലാതെ ക്രെഡൻഷ്യലുകളുടെയും (credentials) വ്യക്തിഗത വിവരങ്ങളുടെയും ശേഖരമായി മാറരുത്.

നിങ്ങൾക്ക് ആവശ്യമുള്ള ഏക നിയമം

ഒരു റിക്വസ്റ്റ് ബോഡി ഡാറ്റ നിർദ്ദേശിക്കുന്നു എന്ന് മാത്രം. അത് അതിന്റെ സ്വന്തം അധികാരം (authority) നിർവചിക്കുന്നില്ല. ക്ലയന്റിന് എന്തിനും അനുമതി ചോദിക്കാം. എന്നാൽ ഏത് ഫീൽഡും ഏത് റോയും സ്ഥിരമായ സ്റ്റോറേജിലേക്ക് (permanent storage) പോകാൻ അനുവദിക്കണമെന്ന് നിങ്ങളുടെ സെർവർ തീരുമാനിക്കുന്നു. ഈ വേർതിരിവ് മനസ്സിൽ വെച്ച് നിങ്ങളുടെ പാച്ചുകൾ (patches) നിർമ്മിക്കുക, അങ്ങനെ മാസ് അസൈൻമെന്റ് നിങ്ങളുടെ ഓതറൈസേഷൻ ലെയറിൽ എത്തുന്നതിന് വളരെ മുമ്പ് തന്നെ നിങ്ങൾ പരിഹരിക്കപ്പെട്ട ഒരു പ്രശ്നമായി മാറും.