बहु-उपयोगकर्ता अनुप्रयोगों में डेटा का उपयोग

बहु-उपयोगकर्ता प्रणालियों को विकसित करते समय डेटा तक पहुंच को प्रतिबंधित करने का मुद्दा लगभग हमेशा उठता है। मुख्य परिदृश्य इस प्रकार हैं:

1. प्रमाणित उपयोगकर्ताओं के लिए डेटा एक्सेस प्रतिबंध
2. प्रमाणीकृत उपयोगकर्ताओं के लिए डेटा तक पहुंच का प्रतिबंध, लेकिन उपयोगकर्ताओं के आवश्यक विशेषाधिकार रखने के लिए नहीं
3. एपीआई के लिए प्रत्यक्ष कॉल के माध्यम से अनधिकृत पहुँच को रोकने
4. खोज क्वेरीज़ में डेटा फ़िल्टर करना और UI तत्वों (तालिकाओं, सूचियों) को सूचीबद्ध करना
5. अन्य उपयोगकर्ताओं द्वारा एक उपयोगकर्ता से संबंधित डेटा के परिवर्तन को रोकना

परिदृश्य 1-3 को अच्छी तरह से वर्णित किया गया है और आमतौर पर अंतर्निहित फ्रेमवर्क टूल का उपयोग करके हल किया जाता है, जैसे कि भूमिका-आधारित या दावा-आधारित प्राधिकरण। लेकिन ऐसी परिस्थितियां जब कोई अधिकृत उपयोगकर्ता "पड़ोसी" के डेटा तक सीधे पहुंच सकता है या हर समय अपने खाते में कोई कार्रवाई कर सकता है। यह सबसे अधिक बार इस तथ्य के कारण होता है कि प्रोग्रामर आवश्यक चेक जोड़ना भूल जाता है। आप एक कोड समीक्षा पर भरोसा कर सकते हैं, या आप वैश्विक डेटा फ़िल्टरिंग नियमों को लागू करके ऐसी स्थितियों को रोक सकते हैं। लेख में उनकी चर्चा की जाएगी।

सूची और टेबल

ASP.NET MVC में डेटा प्राप्त करने के लिए एक विशिष्ट नियंत्रक कुछ इस तरह दिख सकता है:

[HttpGet] public virtual IActionResult Get([FromQuery]T parameter) { var total = _dbContext .Set<TEntity>() .Where(/* some business rules */) .Count(); var items= _dbContext .Set<TEntity>() .Where(/* some business rules */) .ProjectTo<TDto>() .Skip(parameter.Skip) .Take(parameter.Take) .ToList(); return Ok(new {items, total}); } 

इस मामले में, डेटा को फ़िल्टर करने की सारी जिम्मेदारी केवल प्रोग्रामर के पास रहती है। क्या वह याद रखेगा कि शर्त को जोड़ना आवश्यक है कि Where या नहीं?

आप वैश्विक फ़िल्टर का उपयोग करके समस्या को हल कर सकते हैं। हालांकि, एक्सेस को प्रतिबंधित करने के लिए, हमें वर्तमान उपयोगकर्ता के बारे में जानकारी की आवश्यकता है, जिसका अर्थ है कि विशिष्ट क्षेत्रों को आरंभ करने के लिए DbContext के निर्माण को जटिल DbContext होगा।

यदि कई नियम हैं, तो DbContext के कार्यान्वयन को अनिवार्य रूप से "बहुत अधिक" सीखना होगा, जो एकमात्र जिम्मेदारी के सिद्धांत का उल्लंघन करेगा।

पफ वास्तुकला

डेटा तक पहुँच और कॉपी-पेस्ट की समस्याएँ उत्पन्न हुईं क्योंकि उदाहरण में हमने परतों में विभाजन को अनदेखा कर दिया और नियंत्रकों से हम तुरंत व्यापार तर्क परत को दरकिनार करते हुए डेटा एक्सेस लेयर तक पहुँच गए। इस दृष्टिकोण को भी " मोटी गूंगा बदसूरत नियंत्रकों " करार दिया गया है। इस लेख में मैं रिपॉजिटरी, सेवाओं और व्यवसाय तर्क को संरचित करने से संबंधित मुद्दों पर स्पर्श नहीं करना चाहता। ग्लोबल फिल्टर इस का एक अच्छा काम करते हैं, आपको बस उन्हें एक और परत से अमूर्तन में लागू करने की आवश्यकता है।

अमूर्त जोड़ें

.NET में पहले से डेटा एक्सेस करने के लिए IQueryable । ऐसे प्रदाता तक पहुँच के साथ डायरेक्ट एक्सेस को DbContext बदलें:

  public interface IQueryableProvider { IQueryable<T> Query<T>() where T: class; IQueryable Query(Type type); } 

और डेटा तक पहुंचने के लिए, हम यह फ़िल्टर बनाएंगे:

  public interface IPermissionFilter<T> { IQueryable<T> GetPermitted(IQueryable<T> queryable); } 

हम प्रदाता को इस तरह से कार्यान्वित करते हैं कि वह सभी घोषित फिल्टर की खोज करता है और स्वचालित रूप से उन्हें लागू करता है:

  public class QueryableProvider: IQueryableProvider { //       private static Type[] Filters = typeof(PermissionFilter<>) .Assembly .GetTypes() .Where(x => x.GetInterfaces().Any(y => y.IsGenericType && y.GetGenericTypeDefinition() == typeof(IPermissionFilter<>))) .ToArray(); private readonly DbContext _dbContext; private readonly IIdentity _identity; public QueryableProvider(DbContext dbContext, IIdentity identity) { _dbContext = dbContext; _identity = identity; } private static MethodInfo QueryMethod = typeof(QueryableProvider) .GetMethods() .First(x => x.Name == "Query" && x.IsGenericMethod); private IQueryable<T> Filter<T>(IQueryable<T> queryable) => Filters //     .Where(x => x.GetGenericArguments().First() == typeof(T)) //         Queryable<T> .Aggregate(queryable, (c, n) => ((dynamic)Activator.CreateInstance(n, _dbContext, _identity)).GetPermitted(queryable)); public IQueryable<T> Query<T>() where T : class => Filter(_dbContext.Set<T>()); //  EF Core  Set(Type type),    :( public IQueryable Query(Type type) => (IQueryable)QueryMethod .MakeGenericMethod(type) .Invoke(_dbContext, new object[]{}); } 

उदाहरण में फ़िल्टर प्राप्त करने और बनाने के लिए कोड इष्टतम नहीं है। Activator.CreateInstance बजाय Activator.CreateInstance संकलित अभिव्यक्ति पेड़ों का उपयोग करना बेहतर है। कुछ आईओसी कंटेनर खुले जेनरिक के पंजीकरण का समर्थन करते हैं। मैं इस लेख के दायरे से परे अनुकूलन प्रश्न छोड़ दूंगा।

हम फिल्टर का एहसास करते हैं

एक फ़िल्टर कार्यान्वयन इस तरह दिखाई दे सकता है:

  public class EntityPermissionFilter: PermissionFilter<Entity> { public EntityPermissionFilter(DbContext dbContext, IIdentity identity) : base(dbContext, identity) { } public override IQueryable<Practice> GetPermitted( IQueryable<Practice> queryable) { return DbContext .Set<Practice>() .WhereIf(User.OrganizationType == OrganizationType.Client, x => x.Manager.OrganizationId == User.OrganizationId) .WhereIf(User.OrganizationType == OrganizationType.StaffingAgency, x => x.Partners .Select(y => y.OrganizationId) .Contains(User.OrganizationId)); } } 

हम कंट्रोलर कोड को सही करते हैं

  [HttpGet] public virtual IActionResult Get([FromQuery]T parameter) { var total = QueryableProvider .Query<TEntity>() .Where(/* some business rules */) .Count(); var items = QueryableProvider .Query<TEntity>() .Where(/* some business rules */) .ProjectTo<TDto>() .Skip(parameter.Skip) .Take(parameter.Take) .ToList(); return Ok(new {items, total}); } 

बहुत सारे बदलाव नहीं हुए हैं। यह नियंत्रकों से DbContext तक सीधी पहुंच को प्रतिबंधित करने के लिए DbContext हुआ है और यदि फ़िल्टर सही तरीके से लिखे गए हैं, तो डेटा एक्सेस के मुद्दे को बंद माना जा सकता है। फिल्टर काफी छोटे हैं, इसलिए उन्हें परीक्षणों के साथ कवर करना मुश्किल नहीं है। इसके अलावा, इन समान फिल्टर का उपयोग एक प्राधिकरण कोड लिखने के लिए किया जा सकता है जो "विदेशी" डेटा तक अनधिकृत पहुंच को रोकता है। मैं इस लेख को अगले लेख के लिए छोड़ दूंगा।