'कौन क्या देख सकता है' वाली समस्या: अपनी AI से बनी app में user permissions जोड़ना

जिस पल आपकी AI से बनी app सिर्फ़ आपके लिए होना बंद कर देती है, वही पल permissions को एक असली समस्या बना देता है। तब तक हर page सब कुछ दिखाता है। हर list हर row दिखाती है। हर बटन हर किसी के लिए काम करता है। यह एक single-player app है जो multi-player होने का नाटक कर रही है।

फिर आप अपना पहला साथी जोड़ते हैं, या अपना पहला customer, या अपना पहला beta tester — और वो कोई ऐसी चीज़ देख लेता है जो उसे नहीं देखनी चाहिए। शायद वो उसके साथी की salary हो। शायद वो एक ऐसा draft हो जो अभी तैयार नहीं था। शायद वो admin settings हों, ग़लती से उजागर हो गईं।

यह “कौन क्या देख सकता है” वाली समस्या है, और AI app builder प्रोजेक्ट शिप करते वक़्त गैर-तकनीकी builders सबसे बड़ी जो एक चीज़ ग़लत करते हैं, वो यही है। अच्छी ख़बर: इसे सुलझाने के लिए आपको security expert बनने की ज़रूरत नहीं। आपको बस अपने AI builder से इसके बारे में बात करने का एक साफ़ तरीका चाहिए।

आपकी AI से बनी app permissive क्यों शुरू होती है

जब आप किसी AI builder को एक app बताते हैं — “मुझे एक CRM चाहिए जहां मैं clients और notes जोड़ सकूं” — तो builder एक ही चीज़ के लिए optimize करता है: इसे उस इंसान के लिए चलाना जो इसे बता रहा है। default app यह होती है कि “जो भी logged in है वो सब कुछ देख सकता है।” किसी निजी टूल के लिए यह ठीक है। दूसरे user के आते ही यह एक आपदा है।

यह AI app builder में कोई bug नहीं है। यह आपके यह न बताने का कुदरती नतीजा है कि किसे क्या देखने की इजाज़त है। builder को ज़रा भी अंदाज़ा नहीं कि आपकी client list संवेदनशील है, या कि “Notes” में ऐसी चीज़ें हो सकती हैं जो आप clients को नहीं दिखाना चाहते। आपको यह बताना होगा।

दूसरा user जोड़ने से पहले पूछने वाले तीन सवाल

किसी को न्योता देने से पहले, ख़ुद से तीन चीज़ें पूछिए। जवाब लिख लीजिए — आप उन्हें अगले step में अपने AI builder को देंगे।

1. roles कौन से हैं?

लोग नहीं — श्रेणियां। ज़्यादातर apps में दो से चार के बीच होती हैं। एक freelancer portal के लिए: “मैं” और “Client”। एक internal tool के लिए: “Admin,” “Manager,” “Team member”। एक community app के लिए: “Moderator,” “Member,” “Guest”। शुरू में चार roles से आगे जाने के लालच से बचिए। हर role उन नियमों को दोगुना कर देता है जिनका आपको हिसाब रखना है।

2. हर role के लिए, वो क्या देख सकते हैं?

अपनी app के हर page पर मन ही मन जाइए। हर एक के लिए पूछिए: क्या किसी Client को यह page बिल्कुल भी दिखना चाहिए? क्या उसे उस पर का सारा data दिखना चाहिए, या सिर्फ़ अपना? क्या उसे page दिखना चाहिए पर कुछ fields छिपी हुई?

सबसे आसान pattern: owners को सब कुछ दिखता है; बाकी सबको सिर्फ़ वही दिखता है जिसका access उन्हें साफ़-साफ़ दिया गया हो। यह 80% apps के लिए बिना ज़्यादा customization के काम करता है।

3. हर role के लिए, वो क्या कर सकते हैं?

वही कसरत, पर buttons और actions के लिए। क्या एक Member किसी project को delete कर सकता है? क्या एक Client अपनी profile edit कर सकता है पर अपना plan नहीं? क्या एक Manager नए लोगों को न्योता दे सकता है? ज़्यादातर गैर-तकनीकी builders यह step पूरी तरह भूल जाते हैं और ऐसी apps बना बैठते हैं जहां कोई भी logged-in user एक बटन के क्लिक से पूरा database delete कर सकता है।

अपने AI builder से permissions के बारे में बात करना

एक बार जवाब मिल जाएं, तो आपके AI builder के लिए prompt ख़ुद-ब-ख़ुद लिख जाता है। वो कुछ ऐसा दिखता है:

इस app को दो roles को support करने के लिए अपडेट करो: Owner और Client।

Owners सारे clients, सारे projects और सारे invoices देख सकते हैं। Owners कुछ भी बना, edit और delete कर सकते हैं।

Clients सिर्फ़ अपने ख़ुद के projects और अपने ख़ुद के invoices देख सकते हैं। वो client list, team page, या settings page नहीं देख सकते। वो अपने projects देख सकते हैं पर उन्हें edit नहीं कर सकते। वो अपने ख़ुद के invoices देख और pay कर सकते हैं।

जब कोई Client logged in हो, तो Settings और Team के navigation links छिपा दो। अगर कोई Client URL से उन pages पर जाने की कोशिश करे, तो उसे उसके dashboard पर redirect कर दो।

उस prompt में तीन चीज़ें मायने रखती हैं:

page और action के हिसाब से ख़ास रहें। “Clients अपने projects देख सकते हैं” अस्पष्ट है। “Clients /projects page पर अपने ख़ुद के projects देख सकते हैं पर edit नहीं कर सकते” — यह कुछ ऐसा है जिसे एक AI builder सचमुच लागू कर सकता है।
बताएं कि nav के साथ क्या होगा। link छिपाना page को block करने जैसा नहीं है। आपको दोनों चाहिए।
URL टाइप करने वाला मामला भी ढक लें। वरना एक उत्सुक user अपने browser bar में /admin पेस्ट करके सीधे अंदर चला आ सकता है।

वो चार ग़लतियां जो मैं हर हफ़्ते देखता हूं

बहुत से builders को अपनी पहली multi-user app शिप करते देखने के बाद, वही ग़लतियां बार-बार सामने आती हैं:

बटन छिपाना data छिपाना नहीं है। अगर आप अपने AI builder से कहें कि “Clients के लिए delete बटन छिपा दो,” तो बटन screen से ग़ायब हो जाता है। पर पीछे चलने वाला delete operation अब भी काम करता है, अगर किसी को पता चल जाए कि उसे कैसे call करना है। उपाय: builder से यह भी कहिए कि “non-Owner accounts से आने वाली delete requests को backend पर अस्वीकार कर दो।” अगर builder को नहीं पता कि आपकी app में “backend” का क्या मतलब है, तो उससे कहिए कि “action को server-side पर block करो, सिर्फ़ बटन छिपाकर नहीं।”

दो कामों के लिए एक role। लोग “जो पैसे देते हैं” को “जो app इस्तेमाल करते हैं” के साथ गड्डमड्ड कर देते हैं। काम के लिए आपको पैसे देने वाला Client और उस client के लिए आपकी बनाई dashboard इस्तेमाल करने वाला Client-कर्मचारी एक ही role नहीं हैं। अगर आप उन्हें मिला देते हैं, तो आप अगला महीना एक-एक करके नियमों पर पैबंद लगाने में बिता देंगे। दो roles। हमेशा।

पहले ही दिन से users को users न्योता देने देना। “एक साथी को न्योता दें” फ़ौरन जोड़ने का लालच होता है। मत जोड़िए। अपने पहले 10 users के लिए, उन्हें ख़ुद न्योता दीजिए, हाथ से, एक ऐसे admin panel से जो सिर्फ़ आप देख सकते हैं। ख़ुद से होने वाले न्योते permission नियमों की एक पूरी श्रेणी हैं (कौन किसे न्योता दे सकता है? न्योता पाने वालों को कौन सा role मिलता है? क्या वो औरों को न्योता दे सकते हैं?)। तब तक रुकिए जब तक आपको सचमुच इसकी ज़रूरत न पड़े।

AI builder जो कहे उस पर बिना जांचे भरोसा करना। AI builders आपको पूरे यक़ीन से बताएंगे कि permissions सेट हो गई हैं। शायद हो गई हों। शायद न हुई हों। हमेशा एक non-owner के तौर पर log in करके और बुरी चीज़ें करने की कोशिश करके test कीजिए: delete buttons क्लिक कीजिए, admin URLs पेस्ट कीजिए, उन fields को edit कीजिए जिन्हें आपको नहीं कर पाना चाहिए। अगर कुछ भी ऐसा काम करता है जो नहीं करना चाहिए, तो builder से उसे ख़ास तौर पर ठीक करने को कहिए।

किसी को न्योता देने से पहले एक झटपट checklist

दूसरे user को वो पहला न्योता भेजने से पहले, इससे गुज़र जाइए:

मैं अपनी app के roles एक हाथ की उंगलियों पर गिना सकता हूं।
हर role के लिए, मुझे पता है कि उन्हें कौन से pages दिखने चाहिए और कौन से नहीं।
मैंने एक non-owner के तौर पर log in करके पुष्टि कर ली है कि ग़लत pages छिपे हुए हैं।
मैंने एक non-owner के तौर पर browser में एक admin URL पेस्ट करने की कोशिश की और मुझे block कर दिया गया।
मैंने उन delete या edit buttons को क्लिक करने की कोशिश की जो रोक में होने चाहिए और मुझे block कर दिया गया।
अगर कुछ ग़लत हो जाए, तो मेरे पास किसी user का access तेज़ी से हटाने का एक तरीका है।

अगर इनमें से कोई भी बिंदु पास नहीं होता, तो यही अपने AI builder के साथ अगली बातचीत है — न्योता भेजने से पहले, बाद में नहीं।

एक सोच का बदलाव जो मदद करता है

किसी multi-user app के लिए permissions बनाना ज़्यादातर इस बारे में है कि कल्पना करें कि आप अपने सबसे बदतमीज़ user का एक थोड़ा-सा नाक-घुसेड़ू वर्शन हैं। बदनीयत नहीं — बस उत्सुक। वो चीज़ें क्लिक करेंगे। वो URLs पेस्ट करेंगे। वो उस “Settings” page पर जो कुछ है उसे देखने की कोशिश करेंगे जो उन्होंने आपके screenshot में देखा था।

आपका काम — और आपके AI builder का काम — यह पक्का करना है कि जब वो देखें, तो जवाब एक जैसा हो: या तो वो इसे देख सकते हैं क्योंकि यह उनका data है, या वो इसे नहीं देख सकते क्योंकि यह उनका नहीं है। कोई किनारे नहीं। कोई ग़लती से उजागर हुए admin pages नहीं। कोई “मैं भूल गया था कि वो page मौजूद है” नहीं।

ज़्यादातर builders permissions के बारे में तब तक नहीं सोचते जब तक कुछ शर्मिंदगी भरा न हो जाए। अच्छी ख़बर: शिप करने से पहले roles के बारे में 20 मिनट सोचना आपको बाद में उसे ठीक करने के 20 घंटे बचा देता है, साथ ही वो email भी जो आप उस customer को नहीं लिखना चाहते जिसने ग़लत चीज़ देख ली।

कुछ ऐसा बना रहे हैं जिसका एक multi-user पहलू हो? अगली बार जब आप अपने AI app builder के साथ बैठें, तो session की शुरुआत अपनी app के roles को ज़ोर से गिनाने से कीजिए। यह बनाने की सबसे आसान पांच-मिनट वाली आदत है, और यह सबसे बुरी ग़लतियों में से ज़्यादातर को होने से पहले ही पकड़ लेगी।