अनुमतियों के तहत UX / UI कैसे अनुकूलित करें

कई परियोजनाओं में प्रमाणीकरण प्रक्रिया होती है (एक डिग्री या किसी अन्य के लिए)। सभी ज्ञात तकनीकों आदि में कई सर्वोत्तम प्रथाएं लिखी गई हैं। आदि

लेकिन उपयोगकर्ता ने लॉगिन किया और? आखिरकार, वह सब कुछ नहीं कर सकता। यह कैसे निर्धारित किया जाए कि वह क्या देख सकता है और क्या नहीं। कौन से बटन को दबाने का अधिकार है, जो बदल सकता है कि क्या बनाएं या हटाएं।

इस लेख में मैं वेब अनुप्रयोगों पर इन समस्याओं को हल करने के लिए एक दृष्टिकोण पर विचार करना चाहता हूं।

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

और यहां सवाल उठता है कि इसे सही तरीके से कैसे किया जाए।

आइए समस्या को परिभाषित करके शुरू करें।

हमने टोडो ऐप बनाया और इसके विभिन्न प्रकार के उपयोगकर्ता हैं:

USER - सभी कार्यों को देख सकते हैं और उन्हें बदल सकते हैं (V को सेट और हटा सकते हैं), लेकिन आँकड़े हटा या नहीं बना सकते हैं और नहीं देख सकते हैं।

ADMIN - सभी कार्यों को देख सकते हैं और नए बना सकते हैं, लेकिन आंकड़े नहीं देखते हैं।

SUPER_ADMIN - सभी कार्य देख सकते हैं, नए बना सकते हैं और हटा सकते हैं, आँकड़े भी देख सकते हैं।

ऐसी स्थिति में, हम भूमिकाओं के साथ आसानी से प्राप्त कर सकते हैं। हालांकि, स्थिति बहुत बदल सकती है। कल्पना करें कि एक उपयोगकर्ता है जिसके पास ADMIN प्लस कार्य हटाने के समान अधिकार होने चाहिए। या सिर्फ आंकड़ों को देखने की क्षमता वाले USER ।

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

इसी तरह के समाधान कई महान सेवाओं में पाए जा सकते हैं। AWS, Google क्लाउड, SalesForce, आदि।
इसके अलावा, इसी तरह के समाधान कई रूपरेखाओं में पहले से ही लागू हैं, उदाहरण के लिए, Django (अजगर)।

मैं कोणीय अनुप्रयोगों के लिए कार्यान्वयन का एक उदाहरण देना चाहता हूं। (उसी ToDo App के उदाहरण पर)।

पहले आपको सभी संभावित अनुमतियों को निर्धारित करने की आवश्यकता है।

सुविधाओं में विभाजित

1. हमारे पास कार्य और आंकड़े हैं।
2. हम उनमें से प्रत्येक के साथ संभावित क्रियाओं का निर्धारण करते हैं।
   
   • कार्य: बनाएं, पढ़ें, अपडेट करें, हटाएं
   • सांख्यिकी: पढ़ें (हमारे उदाहरण में, केवल देखें)
3. भूमिकाओं और अनुमतियों का एक नक्शा (एमएपी) बनाएं

export const permissionsMap = { todos:{ create:'*', read:'*', update:'*', delete:'*' }, stats:'*' } 

मेरी राय में यह सबसे अच्छा विकल्प है, लेकिन ज्यादातर मामलों में सर्वर कुछ इस तरह लौटेगा:

 export permissions = [ 'todos_create', 'todos_read', 'todos_update', 'todos_delete', 'stas' ] 

कम पठनीय, लेकिन बहुत अच्छा भी।

यदि उपयोगकर्ता के पास सभी संभावित अनुमतियां हैं, तो यह हमारा आवेदन कैसा दिखता है।

आइए USER के साथ शुरू करते हैं, यह वही है जो इसकी अनुमतियाँ दिखती हैं:

 export const USERpermissionsMap = { todos:{ read:'*', update:'*', } } 

1) USER आँकड़े नहीं देख सकता है, अर्थात, वह आँकड़ों के पृष्ठ पर नहीं जा सकता है।

ऐसी स्थितियों के लिए, कोणीय में गार्ड हैं, जो रूट स्तर ( प्रलेखन ) में पंजीकृत हैं।

हमारे मामले में, यह इस तरह दिखता है:

 const routes: Routes = [ // {...Other routes}, { path: 'stats', component: TodoStatisticsComponent, canActivate: [ PermissionsGuardService ], data: { permission: 'stats' }, } ]; 

आपको डेटा में ऑब्जेक्ट पर ध्यान देना चाहिए।

पेरीमेंस = 'आँकड़े', ये अनुमतियाँ हैं जो उपयोगकर्ता के पास इस पृष्ठ तक पहुँचने के लिए होनी चाहिए।

आवश्यक डेटा के आधार पर। अनुमतियाँ और अनुमतियाँ जो अनुमतियाँ गिगार्डसर्विस सर्वर ने हमें दी हैं, यह तय करेगी कि USER को '/ आँकड़े' पृष्ठ पर जाने दिया जाए या नहीं।

 @Injectable({ providedIn: 'root' }) export class PermissionsGuardService implements CanActivate { constructor( private store: Store<any>) { } canActivate(route: ActivatedRouteSnapshot, state: RouterStateSnapshot): Observable<boolean> | boolean { // Required permission to continue navigation const required = route.data.permission; // User permissions that we got from server const userPerms = this.getPermissions(); // verification const isPermitted = checkPermissions(required, userPerms); if (!isPermitted) { alert('ROUTE GUARD SAYS: \n You don\'t have permissions to see this page'); } return isPermitted; } getPermissions() { return localStorage.get('userPermissions') } } 

इस फ़ंक्शन में निर्णय तर्क होता है - क्या USER (userPerms) की सभी अनुमतियों में एक अपरिवर्तनीय अनुमति (आवश्यक) मौजूद है।

 export function checkPermissions(required: string, userPerms) { // 1) Separate feature and action const [feature, action] = required.split('_'); // 2) Check if user have any type of access to the feature if (!userPerms.hasOwnProperty(feature)) { return false; } // 3) Check if user have permission for required action if (!userPerms[feature].hasOwnProperty(action)) { return false; } return true; } 

और ऐसा है। हमारा USER आंकड़े पृष्ठ पर नहीं जा सकता। हालाँकि, वह अभी भी कार्य बना सकता है और उन्हें हटा सकता है।

USER कार्य को हटाने में सक्षम नहीं होने के लिए, यह कार्य रेखा से लाल (X) को निकालने के लिए पर्याप्त होगा।
इस उद्देश्य के लिए हम स्ट्रक्चरल डायरेक्टिव का उपयोग करेंगे।

 <!-- Similar to other Structural Directives in angular (*ngIF, *ngFor..) we have '*' in directive name Input for directive is a required permission to see this btn. --> <button *appPermissions="'todos_delete'" class="delete-button" (click)="removeSingleTodo()"> X </button> 

 @Directive({ selector: '[appPermissions]' }) export class PermissionsDirective { private _required: string; private _viewRef: EmbeddedViewRef<any> | null = null; private _templateRef: TemplateRef<any> | null = null; @Input() set appPermissions(permission: string) { this._required = permission; this._viewRef = null; this.init(); } constructor(private templateRef: TemplateRef<any>, private viewContainerRef: ViewContainerRef) { this._templateRef = templateRef; } init() { const isPermitted = checkPermissions(this._required, this.getPermissions()); if (isPermitted) { this._viewRef = this.viewContainerRef.createEmbeddedView(this.templateRef); } else { console.log('PERMISSIONS DIRECTIVE says \n You don\'t have permissions to see it'); } } getPermissions() { localStorage.get('userPermissions') } } 

अब USER DELETE बटन नहीं देखता है, लेकिन फिर भी नए कार्य जोड़ सकता है।

एक इनपुट फ़ील्ड को निकालने के लिए - हमारे सभी प्रकार के एप्लिकेशन को खराब कर देगा। इस स्थिति में सही समाधान इनपुट फ़ील्ड को disable ।

हम पाइप का उपयोग करेंगे।

 <!-- as a value `permissions` pipe will get required permissions `permissions` pipe return true or false, that's why we have !('todos_create' | permissions) to set disable=true if pipe returns false --> <input class="centered-block" [disabled]="!('todos_create' | permissions)" placeholder="What needs to be done?" autofocus/> 

 @Pipe({ name: 'permissions' }) export class PermissionsPipe implements PipeTransform { constructor(private store: Store<any>) { } transform(required: any, args?: any): any { const isPermitted = checkPermissions(required, this.getPermissions()); if (isPermitted) { return true; } else { console.log('[PERMISSIONS PIPE] You don\'t have permissions'); return false; } } getPermissions() { return localStorage.get('userPermissions') } } 

और अब USER केवल कार्यों को देख सकता है और उन्हें बदल सकता है (V / X)। हालाँकि, हमारे पास अभी भी एक और बटन है जिसे 'क्लियर पूरा' कहा जाता है।

मान लें कि हमारे पास निम्नलिखित उत्पाद प्रबंधक आवश्यकताएँ हैं:

1. 'क्लियर कम्प्लीटेड' बटन हर किसी को और हमेशा दिखना चाहिए।
2. यह भी क्लिक करने योग्य होना चाहिए।
3. यदि संबंधित अनुमतियों के बिना USER बटन दबाता है, तो एक संदेश दिखाई देना चाहिए।

रचनात्मक निर्देश हमारी मदद नहीं करेगा, साथ ही साथ पाइप भी।
घटक कार्यों में अनुमतियों की जाँच लिखना भी बहुत सुविधाजनक नहीं है।

हमें केवल क्लिक और बाध्य फ़ंक्शन के निष्पादन के बीच एक अनुमतियों की जांच करना है।

मेरी राय में, यह सज्जाकारों का उपयोग करने के लायक है।

 export function Permissions(required) { return (classProto, propertyKey, descriptor) => { const originalFunction = descriptor.value; descriptor.value = function (...args: any[]) { const userPerms = localStorage.get('userPermissions') const isPermitted = checkPermissions(required, userPerms); if (isPermitted) { originalFunction.apply(this, args); } else { alert('you have no permissions \n [PERMISSIONS DECORATOR]'); } }; return descriptor; }; } 

 @Component({ selector: 'app-actions', templateUrl: './actions.component.html', styleUrls: ['./actions.component.css'] }) export class ActionsComponent implements OnInit { @Output() deleteCompleted = new EventEmitter(); constructor() { } @Permissions('todos_delete') public deleteCompleted() { this.deleteCompleted.emit(); } } 

स्पीकर एक अलग लेख के लायक हैं।

हमारा अंतिम परिणाम:

परिणाम:

यह दृष्टिकोण हमें आसानी से और गतिशील रूप से हमारे यूएक्स को उन अनुमतियों के अनुसार अनुकूलित करने की अनुमति देता है जो उपयोगकर्ता के पास है।

और सबसे महत्वपूर्ण बात यह है कि इसके लिए हमें hammer * एनजीआईएफ ’टेम्प्लेट में सभी कंपोनेंट्स या हैमर को सेवाएं देने की आवश्यकता नहीं है।

पूरा आवेदन पूरा हो गया है ।

मुझे टिप्पणी करने में खुशी होगी।