प्लेयराइट संदर्भ पुन: उपयोग विरुद्ध भंडारण अवस्था CAPTCHA के लिए

सारांश

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

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

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

CapSolver एक स्वीकृत ब्राउज़र कार्य प्रवाह में समर्थित कैपचा कार्य का समाधान कर सकता है। सही ब्राउज़र-स्टेट दृष्टिकोण चुनना आपके एप्लिकेशन को उस परिणाम को सही जगह पर पहुंचाने में मदद करता है और यह जांचने में मदद करता है कि मूल कार्य वास्तव में पूरा हो गया है।

लिव संदर्भ और स्टोरेज स्टेट में क्या अंतर है?

एक लिव ब्राउज़र संदर्भ एक सक्रिय ब्राउज़र वातावरण होता है जिसमें पृष्ठ होते हैं, जबकि स्टोरेज स्टेट एक समर्थित संगृहीत डेटा की स्नैपशॉट होती है। स्नैपशॉट पूरे चल रहे ब्राउज़र को सीरियलाइज नहीं करता है।

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

ब्राउज़रकॉन्टेक्स्ट स्टोरेज-स्टेट संदर्भ में वह जानकारी दस्तावेज़ की गई है जो स्नैपशॉट में होती है और उपलब्ध विकल्प होते हैं। कुकीज़ और स्थानीय स्टोरेज सामान्य उपयोग के केंद्र होते हैं; अतिरिक्त स्टोरेज श्रेणियां दस्तावेज़ किए गए विकल्पों और स्थापित संस्करण पर निर्भर करती हैं। अपने एप्लिकेशन द्वारा उपयोग किए गए सभी स्थिति स्रोतों के बारे में नहीं मानें।

जीवित पृष्ठ को जारी रखना

एक अस्तित्व में पृष्ठ को जारी रखना उस वास्तविक दस्तावेज़ और उसके वर्तमान जावास्क्रिप्ट निष्पादन वातावरण को बरकरार रखता है जब तक कि पृष्ठ सक्रिय रहता है। जब एक एजेंट कार्य एक कैपचा पर रुक जाता है और उसी फॉर्म को पूरा करने की आवश्यकता होती है, तो यह आमतौर पर स्पष्ट शुरुआत बिंदु होता है।

सततता के सीमाएं भी होती हैं। वेबसाइट विज़ार्ड को फिर से लोड कर सकती है, सत्र समाप्त हो सकता है, एक छिपा हुआ क्षेत्र बदल सकता है, या पृष्ठ को नेविगेट कर सकता है। एक जीवित ऑब्जेक्ट रेफरेंस यह गारंटी नहीं दे सकता कि पहले के चुनौती अभी भी ताजा है। एक देरी के परिणाम के लिए पृष्ठ की पुनः जांच करें।

एक ही संदर्भ में अन्य पृष्ठ खोलना

एक नया पृष्ठ संदर्भ-स्तर की कुकीज़ का उपयोग कर सकता है जबकि अलग दस्तावेज़ और फॉर्म होता है। जब एक एजेंट टूल दोनों पृष्ठों को एक "सत्र" के हिस्से के रूप में वर्णित करता है, तो इस अंतर को भूल जाना आसान होता है।

अगर सॉल्वर परिणाम मूल पृष्ठ के चुनौती के लिए है, तो दूसरा पृष्ठ खोलना पूरे अंतरक्रिया के लिए निर्देश नहीं होता है। अपने ऑपरेशन के लिए विशिष्ट पृष्ठ की निगरानी करें, और केवल इसलिए रिडायरेक्ट न करें क्योंकि एक अन्य टैब के पास समान URL है।

सहेजे गए स्टोरेज स्टेट से शुरू करना

सहेजे गए स्टेट को लोड करना एक नए संदर्भ को समर्थित स्थायी डेटा के साथ तैयार कर सकता है। यह पुराने पृष्ठ के डीओएम, अपलोड न किए गए फॉर्म, सक्रिय कॉलबैक, या अपूर्ण नेटवर्क ऑपरेशन की बहाली नहीं करता है।

प्लेयराइट के स्थिति-पुनर्उपयोग दिशा-निर्देश में स्थिति पुनर्उपयोग और इसके सुरक्षा प्रभावों की व्याख्या की गई है, और यह नोट करता है कि सेशन स्टोरेज के अलग से निपटान की आवश्यकता होती है। इस तुलना के लिए, व्यावहारिक बिंदु सरल है: एक संगृहीत सत्र एक निलंबित ब्राउज़र प्रक्रिया नहीं है। एक नया पृष्ठ को अपने वर्तमान एप्लिकेशन स्थिति को स्थापित करना होता है।

कौन सी दृष्टिकोण प्रत्येक कैपचा वर्कफ़्लो के लिए उपयुक्त है?

आपके द्वारा बरकरार रखने की आवश्यकता वाले कार्य और बरकरार रखने की आवश्यकता वाली आइसोलेशन के आधार पर दृष्टिकोण चुनें। एक कार्य में उपयोग करना उपयोगी होता है; अलग-अलग कार्यों के बीच आइसोलेशन उपयोगी होता है जो अपनी स्थिति साझा नहीं करना चाहते हैं।

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

कोई जनरल नियम नहीं है कि संदर्भ पुनर्उपयोग कैपचा को रोकता है। चुनौती निर्णय लेने वाले एप्लिकेशन और प्रदाता के अधिकार होते हैं। सततता को अपने कार्य प्रवाह स्थिति के नुकसान से बचाने के तरीके के रूप में लें, न कि वेबसाइट के द्वारा भविष्य के अनुरोधों के वर्गीकरण के बारे में एक वादा के रूप में।

स्वतंत्र ऑटोमेटेड परीक्षण के लिए, प्लेयराइट के आइसोलेशन मॉडल का स्पष्ट लाभ है: एक परीक्षण की कुकीज़ और स्टोरेज अगले परीक्षण के परिणाम को ध्यान से निर्धारित नहीं करती है। असंबंधित परीक्षणों में एक जीवित संदर्भ के पुनर्उपयोग से विनिर्देश आवश्यकताओं को छिपा सकता है या विफलताओं को निष्पादन क्रम पर निर्भर कर सकता है।

एक ही परीक्षण या अनुमोदित एजेंट कार्य में, प्रत्येक टूल कॉल के बाद संदर्भ की पुनर्स्थापना करना विपरीत समस्या उत्पन्न कर सकता है। कार्य प्रवाह बार-बार जिस जानकारी को बरकरार रखने की आवश्यकता होती है, उसे बरकरार रखता है। पहले कार्य की सीमा निर्धारित करें, फिर उस सीमा के लिए केवल स्थिति बरकरार रखें।

कैपचा सॉल्वर कहां फिट होता है?

कैपचा सॉल्वर ब्राउज़र कार्य में समर्थित चुनौति चरण में होता है। यह उस चरण के आसपास प्रत्येक पृष्ठ, संदर्भ या एप्लिकेशन सत्र के पूर्ण जीवन चक्र के मालिक नहीं होता है।

CapSolver Core SDK संदर्भ के अनुसार, समाधान को पैरामीटर और ब्राउज़र-ओरिएंटेड ऑपरेशन से अलग करें जो प्लेयराइट पृष्ठ का उपयोग करते हैं। एक एकीकरण चुनते समय, जांचें कि कौन सा ऑब्जेक्ट या इनपुट इसे स्वीकार करता है और क्या यह वापस करता है। एक वापसी टोकन और ब्राउज़र भरने की ऑपरेशन बुलाने वाले एप्लिकेशन के लिए अलग जिम्मेदारियां निर्दिष्ट करते हैं।

ब्राउज़र-मालिक कार्य प्रवाह के लिए, यह निर्धारित करें कि एकीकरण किस पृष्ठ को प्राप्त करता है। एक पैरामीटर-आधारित कार्य के लिए, यह निर्धारित करें कि परिणाम आपके एप्लिकेशन के दस्तावेज़ के प्रवाह के माध्यम से कैसे लक्षित पृष्ठ तक पहुंचेगा। यह नहीं मानें कि एक टोकन प्राप्त करना सभी पृष्ठों को अपडेट करता है जो संदर्भ में हैं।

पहले प्लेयराइट reCAPTCHA वर्कफ़्लो लेख कैपचा सॉल्वर के स्थान के बारे में ब्राउज़र ऑटोमेशन के बारे में बताता है। इस तुलना में जीवित पृष्ठ के लिए एक अंतिम प्रयास बनाए रखने या स्पष्ट रूप से प्रारंभिक स्थिति के साथ एक नई ऑपरेशन शुरू करने के बीच जीवन चक्र निर्णय जोड़ा गया है।

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

अपना CapSolver बोनस कोड जमा करें

अपने स्वचालन बजट को तत्काल बढ़ाएं!
CapSolver खाता में अपने खाते को बढ़ाते समय बोनस कोड CAP26 का उपयोग करें ताकि प्रत्येक भरोसा पर 5% बोनस मिले — कोई सीमा नहीं।
अपने CapSolver डैशबोर्ड में अब इसे जमा करें

क्या होता है जब कैपचा परिणाम पृष्ठ बदल जाने के बाद आता है?

एक पृष्ठ परिवर्तन के बाद आने वाले परिणाम को जमा करने के लिए वर्तमान ऑपरेशन के साथ एक ताजा जांच की आवश्यकता होती है। एक ही संदर्भ बनाए रखना हर पहले परिणाम को ताजा नहीं बनाता है।

मान लीजिए एक एजेंट एक कंपनी के स्टेजिंग साइट पर एक उत्पाद जांच पूरा कर रहा है। यह फॉर्म भरता है और एक समर्थित चुनौति तक पहुंचता है। एक सॉल्व अभी भी चल रहा है, एक अलग क्रिया पृष्ठ को फिर से लोड करती है। ब्राउज़र अभी भी उसी संदर्भ में है, लेकिन दस्तावेज़ और चुनौति बदल सकते हैं।

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

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

अपने स्टोर्ड ब्राउज़र-स्टेट फाइल में पूर्ण टोकन के एक भंडार के बजाय न बनाएं। एक स्टोर्ड कुकी, एक सहेजे गए स्थानीय-स्टोरेज एंट्री, और एक चुनौति प्रतिक्रिया अलग-अलग वस्तु हैं जिनके अलग-अलग जीवनकाल होते हैं। अन्य कैपचा प्रकार के लिए, अपने स्वयं के दस्तावेज़ किए गए परिणाम और सत्र की आवश्यकता की जांच करें, बजाय reCAPTCHA या Turnstile नियमों की नकल करने के।

एआई एजेंट के लिए जारी रखने या फिर से शुरू करने का चयन कैसे करना है?

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

एक अनुमति दिए गए अनुसंधान को जारी रखें

मान लीजिए एक एजेंट एक अनुमति दिए गए ब्राउज़र मार्ग के माध्यम से एक सार्वजनिक रिकॉर्ड की जांच कर रहा है। वर्तमान पृष्ठ अपेक्षित खोज दिखा रहा है, समर्थित चुनौति उस पृष्ठ के लिए है, और परिणाम की अवधि समाप्त नहीं हुई है। एक ही पृष्ठ को जारी रखना सॉल्वर चरण को अनुसंधान से जोड़ता है।

सफलता जांच अपेक्षित रिकॉर्ड या एक वैध अनुपस्थिति प्रतिक्रिया की पुष्टि करनी चाहिए। एक साफ विज़ार्ड अकेले अपेक्षित डेटा के लिए अनुसंधान के लिए बराबर प्रमाण नहीं है। मूल खोज और अंतिम पृष्ठ परिणाम को ऑपरेशन रिकॉर्ड में एक साथ रखें।

एक नए स्वतंत्र परीक्षण शुरू करें

मान लीजिए एक QA टीम को दो अलग-अलग जांच-फॉर्म विन्यासों के परीक्षण करने की आवश्यकता है। प्रत्येक परीक्षण के लिए अपने स्थिति के अनुसार सेटअप शुरू करना चाहिए। एक ताजा संदर्भ में पहले परीक्षण के स्टोर्ड स्थिति के प्रभाव को रोकने में मदद मिलती है।

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

पृष्ठ खो जाने के बाद फिर से शुरू करें

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

एक स्टेट फाइल लोड होने के कारण रुके हुए कार्य को "बहाल किया गया" कहकर रिपोर्ट न करें। दृश्य प्रमाण यह है कि इच्छित एप्लिकेशन कार्य एक बार पूरा हो गया है, सही इनपुट और प्रतिक्रिया के साथ।

क्या ऑपरेशनल व्यापार विनिमय हैं?

संदर्भ पुनर्उपयोग कम सेटअप कार्य के बदले अधिक रखरखाव के आवश्यकता के बीच एक व्यापार विनिमय होता है। समय या सॉल्वर लागत में बचत एप्लिकेशन पर निर्भर करती है; दृष्टिकोण द्वारा कोई निश्चित बचत नहीं होती है।

एक लंबे समय तक खुले संदर्भ के लिए यह आवश्यक है कि कौन इसका उपयोग कर सकता है और जब इसे बंद करना चाहिए। एक स्नैपशॉट के लिए स्टोरेज, एक्सेस, समाप्ति और बदले के नियम होने चाहिए। ताजा संदर्भ के लिए दोहराए गए सेटअप की आवश्यकता होती है लेकिन स्वतंत्र स्थिति के बीच अंतर समझने में आसान होता है।

अपनी टीम द्वारा छिपे ब्राउज़र व्यवहार पर निर्भर किए बिना स्पष्ट नीति चुनें। एक सक्रिय कार्य के पास एक ज्ञात पृष्ठ मालिक, एक सीमित चुनौति बजट और एक परिभाषित पूर्णता शर्त होनी चाहिए। जब आवश्यक हो तो असंबंधित उपयोगकर्ताओं और ग्राहक भार को अलग रखें भले ही ब्राउज़र प्रक्रिया के साथ साझा करना सुविधाजनक लगे।

विफलता निदान करते समय, लॉग करें कि संदर्भ पहचानकर्ता, पृष्ठ पहचानकर्ता, ऑपरेशन पहचानकर्ता हैं और क्या पृष्ठ नेविगेट या फिर से लोड हुआ। ये एप्लिकेशन-जनित संबंध लेबल हैं, कैपचा-प्रदाता पैरामीटर नहीं। वास्तविक कुकीज़, टोकन और सहेजे गए सत्यापन सामग्री को नियमित लॉग में रखें।

इस छोटी मात्रा के जीवन चक्र की जानकारी व्यावहारिक प्रश्नों का उत्तर देती है: क्या सॉल्वर सही पृष्ठ के साथ काम कर रहा था, क्या पृष्ठ प्रस्तुति से पहले बदल गया था, और क्या एप्लिकेशन ने मूल कार्य की पुष्टि की थी? यह एक एकल बूलियन के साथ "सत्र पुनर्उपयोग किया गया" के रूप में लेबल किए गए से अधिक उपयोगी है।

CapSolver के साथ विश्वसनीय स्वचालन कार्य प्रवाह बनाएं

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

अक्सर पूछे जाने वाले प्रश्न

प्रश्न: क्या प्लेयराइट स्टोरेज स्टेट पूर्ण हो चुके कैपचा को संरक्षित करता है?

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

प्रश्न: क्या एक ही संदर्भ में एक नया पृष्ठ खोलना वही फॉर्म जारी रखता है?

नहीं। नए पृष्ठ के पास संदर्भ-स्तर की कुकीज़ हो सकती हैं, लेकिन एक अलग दस्तावेज़ होता है। एक फॉर्म और प्रयास के लिए आवश्यक चुनौति परिणाम को एक टैब के केवल URL के आधार पर चुनने के बजाय बरकरार रखें।

प्रश्न: क्या प्रत्येक एआई एजेंट टूल एक ताजा ब्राउज़र संदर्भ बनाता है?

नहीं। एक अधिकृत कार्य में एक दूसरे के साथ संबंधित चरणों के लिए एक ही जीवित पृष्ठ की आवश्यकता हो सकती है, जबकि असंबंधित उपयोगकर्ता या स्वतंत्र परीक्षण के लिए आइसोलेशन आवश्यक हो सकता है। टास्क सीमा के आधार पर संदर्भ जीवन चक्र को निर्धारित करें, न कि टूल कॉल की संख्या के आधार पर।

प्रश्न: क्या संदर्भ पुनर्उपयोग छोटे कैपचा आउटपुट की गारंटी देता है?
नहीं। लक्ष्य प्रणाली तय करती है कि चुनौती की आवश्यकता कब होती है। पुनर्उपयोग कार्य प्रवाह स्थिति को बरकरार रख सकता है, लेकिन यह चुनौती की आवृत्ति, स्वीकृति या समाधानकर्ता लागत के बारे में दस्तावेजीकृत गारंटी नहीं है।

प्रश्न: क्या कैपसॉल्वर मेरे प्लेयराइट सत्रों को स्वचालित रूप से प्रबंधित करता है?

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