जब किसी Playwright टेस्ट या स्क्रैपर को ऑथेंटिकेशन चाहिए, तो हर रन में शुरू से लॉगिन करने की आमतौर पर ज़रूरत नहीं होती। आम तरीका यह है कि एक बार लॉगिन करें, cookies और संबंधित ब्राउज़र स्टेट storageState से सेव करें, फिर बाद के रन में वही स्टेट लोड करके उसी सत्र का फिर से उपयोग करें। लेकिन सेव किया storageState फ़ाइल होना यह नहीं कहता कि लॉगिन हमेशा चलता रहेगा। सत्र खत्म हो सकता है, सर्वर उसे रद्द कर सकता है, या वह शुरुआत में ही सही से लोड न हो।
अगर आप अपना ही अकाउंट ऑटोमेट कर रहे हैं और रोज़ वाले ब्राउज़र में पहले से साइन इन हैं, तो दूसरा विकल्प है: उसी मौजूदा ब्राउज़र सत्र का सीधे फिर से उपयोग। ego (lite) AI एजेंटों को उस ब्राउज़र में काम करने देता है जिसमें उन्हें चाहिए वाला लॉगिन स्टेट पहले से है, और हर काम को उसके अपने Space में अलग रखता है। अगर काम वेरिफ़िकेशन कोड, QR लॉगिन, या ऐसे कदम तक पहुँचे जिसमें आपकी ज़रूरत है, तो MFA को ऑटोमेट करने की कोशिश के बजाय दिख रहे ब्राउज़र में नियंत्रण ले सकते हैं।
जो भी तरीका अपनाएँ, मकसद एक है: पक्का करें कि ऑटोमेशन के पास वाकई वैध ऑथेंटिकेटेड सत्र है। कोई रन जो अचानक लॉगिन पेज पर पहुँचा दे, कोई API जो 401 लौटाए, या लॉगिन के बाद वाला एलिमेंट जो कभी आए ही नहीं, तीन अलग मुद्दे लग सकते हैं: नेविगेशन, अनुमतियाँ, या एक सेलेक्टर समस्या, जबकि ये सब एक ही टूटे सत्र की ओर इशारा कर सकते हैं। नीचे के सेक्शन में हम एक दोहराए जा सकने वाले लोकल सेटअप से दिखाएँगे कि Playwright में ऑथेंटिकेशन स्टेट को कैसे सेव, रीयूज़, वेरिफ़ाई और रिफ़्रेश करें।
टूटा हुआ Playwright लॉगिन कैसा दिखता है
फ़िक्स्चर रन में एक रद्द सत्र ने तीनों लक्षण एक साथ दिए। सर्वर-साइड सत्र साफ़ होने के बाद, सेव किए स्टेट का फिर से उपयोग करने वाला कॉन्टेक्स्ट लॉगिन पेज पर रीडायरेक्ट हुआ, next पैरामीटर डैशबोर्ड की ओर इशारा कर रहा था, ऑथेंटिकेटेड JSON एंडपॉइंट की जांच ने 401 लौटाया, और डैशबोर्ड टेबल का इंतज़ार कॉन्फ़िगर किए 3 सेकंड बाद टाइम आउट हो गया।
सार्वजनिक the-internet लॉगिन पर यही विफलता bounce है। बिना जीवित सत्र /secure खोलने पर /login आता है और लाल फ्लैश You must login to view the secure area दिखता है। नीचे के callout वाली URL जाँच यही है: ब्राउज़र लॉगिन फ़ॉर्म पर है, locator वाली पेज पर नहीं। यह स्क्रीनशॉट वही bounce है। यह सबूत नहीं कि Logout ने storageState फ़ाइल मिटा दी। the-internet Logout मौजूदा विंडो सत्र खत्म करता है; डिस्क पर पहले से लिखी फ़ाइल कुकी मरने तक /secure फिर खोल सकती है।
तीसरा लक्षण महंगा है। लॉगिन के बाद वाले एलिमेंट पर लोकेटर का टाइम आउट यह नहीं कहता कि लोकेटर गलत है; यह कहता है कि जो पेज आप देख रहे हैं वह वह पेज नहीं जिसे आपने माना था। ऊपर वाले रन में टेबल रेंडर ही नहीं हुई क्योंकि ब्राउज़र लॉगिन फ़ॉर्म पर बैठा था। इसे सेलेक्टर समस्या मानना ऐसी क्वेरी को पैच करने ले जाता है जो कभी टूटी ही नहीं थी।
ऑथेंटिकेशन फेल होने के पीछे चार मूल कारण
ऑथेंटिकेशन फेल चार कारणों में बँटते हैं, और हर एक का अलग सुधार है। पैच से पहले वर्गीकरण ही सुधार को एक और wait स्टेटमेंट बनने से रोकता है।
1. स्टेट कभी लोड ही नहीं हुआ
बिना storageState बनाए गए कॉन्टेक्स्ट साइन आउट शुरू होते हैं, पिछली रन में जो भी हुआ हो। वही नतीजा तब भी आता है जब फ़ाइल गलत पल पर सेव हो, रिलेटिव पाथ कहीं और रिज़ॉल्व हो, या सेटअप स्टेप ऐसे प्रोजेक्ट में चले जिसका स्टेट डिपेंडेंट प्रोजेक्ट तक न जाए। पहचान यह है कि बिल्कुल नया कॉन्टेक्स्ट फेल होने वाले जैसा ही व्यवहार करता है: दोनों साइन आउट हैं।
2. Cookie मौजूद है लेकिन मरा हुआ है
सत्र cookie मौजूद हो सकता है, सही डोमेन और फ़्लैग रख सकता है, और फिर भी सर्वर उसे ठुकरा सकता है। सत्र cookies की अपनी उम्र होती है, और सर्वर किसी भी समय एक को रद्द कर सकता है, जिसमें रीडिप्लॉय, पासवर्ड बदलाव, या आइडल टाइमआउट शामिल हैं। Cookie का expires फ़ील्ड संकेत है, गारंटी नहीं: सर्वर-साइड सत्र पहले मर सकता है। यही मामला फ़िक्स्चर स्पष्ट revoke कॉल से दोहराता है।
3. कॉन्टेक्स्ट के बीच आइसोलेशन
Cookies और localStorage ब्राउज़र कॉन्टेक्स्ट के होते हैं, ब्राउज़र के नहीं। एक कॉन्टेक्स्ट से स्टेट सेव करके यह उम्मीद करना कि अलग कॉन्फ़िगर कॉन्टेक्स्ट उसे साझा करेगा, चुपचाप फेल होता है। यही समानांतर worker पर लागू होता है: हर worker को अपना कॉन्टेक्स्ट मिलता है, इसलिए हर worker को अपनी स्टोरेज फ़ाइल या अपना लॉगिन स्टेप चाहिए। यह आइसोलेशन एक फ़ीचर है। यही वजह भी है कि एक जगह काम करने वाला सत्र दूसरी जगह गायब लगता है।
4. SSO रीडायरेक्ट श्रृंखलाएँ
सिंगल साइन-ऑन में जो ऐप आप चाहते हैं वह शायद ही वह origin होता है जो सत्र रखता है। लॉगिन दूसरे डोमेन के आइडेंटिटी प्रोवाइडर पर रीडायरेक्ट करता है, प्रोवाइडर अपनी cookies सेट करता है, और नियंत्रण कोड या टोकन के साथ ऐप पर लौटता है। श्रृंखला पूरी होने से पहले स्टेट सेव करने से सत्र का एक हिस्सा कैप्चर होता है और IdP cookies छूट जाती हैं, और अगली रन वही रीडायरेक्ट दोहराती है। भरोसेमंद पैटर्न यह है कि सेव से पहले अंतिम ऐप URL और ऑथेंटिकेटेड मार्कर का इंतज़ार करें, ताकि स्टेट फ़ाइल श्रृंखला में शामिल हर origin ले जाए।
एक बार लॉगिन करें और स्टेट सही तरीके से सेव करें
एक-बार-लॉगिन फ़्लो छोटा है: नेविगेट करें, ऑथेंटिकेट करें, ऑथेंटिकेटेड स्टेट की पुष्टि करें, फिर storageState फ़ाइल में लिखें। पुष्टि वाला कदम ही काम करने वाली स्टेट फ़ाइल को कभी-कभी न चलने वाली से अलग करता है।
import { chromium } from "playwright";
const browser = await chromium.launch();
const context = await browser.newContext();
const page = await context.newPage();
await page.goto("https://app.example.com/login");
await page.fill("input[name=email]", process.env.APP_EMAIL);
await page.fill("input[name=password]", process.env.APP_PASSWORD);
await page.click("button[type=submit]");
// Wait for the authenticated destination, not just for the click to land.
await page.waitForURL("**/dashboard");
// Verify before saving: an authenticated element plus a 200 from the API.
await page.waitForSelector("#revenue-table");
const probe = await context.request.get("https://app.example.com/api/summary");
if (probe.status() !== 200) throw new Error("login did not take");
await context.storageState({ path: "playwright/.auth/user.json" });
await browser.close();फ़िक्स्चर रन में यह कदम लॉगिन पेज खोलने से स्टेट फ़ाइल लिखने तक 119 मिलीसेकंड लिया। फ़ाइल में एक cookie था, सर्वर द्वारा जारी सत्र पहचानकर्ता, और जांच ने 200 लौटाया। ऐसे आँकड़े फ़िक्स्चर की संपत्ति हैं, लेकिन जाँच का आकार ही स्थानांतरित होता है: गंतव्य URL वेरिफ़ाई करें, दिख रहा ऑथेंटिकेटेड एलिमेंट वेरिफ़ाई करें, ऑथेंटिकेटेड एंडपॉइंट वेरिफ़ाई करें, और तभी सहेजें।
नीचे वाला headed रन the-internet.herokuapp.com पर है, fixture डैशबोर्ड पर नहीं। 119 मिलीसेकंड fixture के साथ रहते हैं। स्क्रीनशॉट सार्वजनिक लॉगिन पर वही सेव आकार दिखाता है: प्रमाणीकरण के बाद /secure, Logout दिख रहा है, और Claude /tmp/pw-auth.json की जाँच कर रहा है।
टेस्ट सूट में यही विचार एक सेटअप प्रोजेक्ट से व्यक्त होता है जो फ़ाइल बनाता है और डिपेंडेंट प्रोजेक्ट उसे इस्तेमाल करते हैं, वह पैटर्न जो आधिकारिक ऑथेंटिकेशन गाइड बताता है। स्क्रिप्ट और स्क्रैपर के लिए ऊपर वाला क्रम पूरा फ़्लो है। दोनों ही स्थिति में फ़ाइल एक क्रेडेंशियल है: इसमें जीवित सत्र cookies हैं, इसलिए इसे पासवर्ड जितनी सावधानी से रखें और वर्शन कंट्रोल से बाहर रखें।
टेस्ट और स्क्रैपर में सेव किए स्टेट का फिर से उपयोग
रीयूज़ कॉन्टेक्स्ट बनाने पर एक पंक्ति का बदलाव है। स्क्रिप्ट में फ़ाइल कॉन्टेक्स्ट को दें। Playwright टेस्ट सूट में इसे प्रोजेक्ट या टेस्ट फ़ाइल पर सेट करें ताकि हर worker एक ही साइन-इन स्टेट से शुरू हो।
// Script: create the context from the saved state.
const context = await browser.newContext({
storageState: "playwright/.auth/user.json",
});
// Test: use the state for this file (or configure it per project).
test.use({ storageState: "playwright/.auth/user.json" });फ़िक्स्चर रन में सेव फ़ाइल से बने नए कॉन्टेक्स्ट ने बिना लॉगिन स्टेप के 6 मिलीसेकंड में सुरक्षित डैशबोर्ड तक पहुँचा, और ऑथेंटिकेटेड जांच ने अपेक्षित पेलोड के साथ 200 लौटाया। दिलचस्प संख्या 6 मिलीसेकंड नहीं है; दिलचस्प यह है कि फ़्लो में सिवाय इसके कुछ नहीं बदला कि कॉन्टेक्स्ट का स्टेट कहाँ से आया।
रीयूज़ स्क्रीनशॉट वही सार्वजनिक साइट है। नए headed context ने /tmp/pw-auth.json लोड किया, लॉगिन फ़ॉर्म छोड़ा, और पेज पर पहले से Logout के साथ /secure खोला। 6 मिलीसेकंड अभी भी fixture का समय है।
यह जानना ज़रूरी है कि स्टेट फ़ाइल क्या ले जाती है और क्या नहीं। इसमें हर उस origin की cookies हैं जिसे कॉन्टेक्स्ट ने छुआ, और origin के हिसाब से localStorage प्रविष्टियाँ। इसमें IndexedDB, session storage, या service worker स्टेट नहीं होता। जो ऐप अपना टोकन IndexedDB में रखते हैं उन्हें इसलिए अतिरिक्त कैप्चर कदम या फिर से लॉगिन चाहिए; यह उम्मीद करना कि storageState उन्हें कवर करेगा, भूतिया फेल की आम वजह है। Cookies खुद डोमेन, पाथ और फ़्लैग से शासित होती हैं, जिनका वर्णन MDN कुकी गाइड और Set-Cookie संदर्भ में है।
खत्म या रद्द हुए सत्र की पहचान
सबसे सस्ता डिटेक्टर महंगे काम से पहले की गई ऑथेंटिकेटेड रिक्वेस्ट है। ज़्यादातर ऐप का एक छोटा एंडपॉइंट होता है जो मौजूदा यूज़र, कोई गिनती, या कॉन्फ़िगरेशन ऑब्जेक्ट लौटाता है, और उसका स्टेटस कोड सत्र का स्टेटस कोड होता है। एक रिक्वेस्ट मिलीसेकंड लेती है; स्क्रैप के बीच में फेल पता चलना पूरा रन ले लेता है।
async function sessionIsAlive(context) {
const probe = await context.request.get(
"https://app.example.com/api/summary",
{ failOnStatusCode: false },
);
return probe.status() === 200;
}
if (!(await sessionIsAlive(context))) {
await loginAndSaveState(context);
}Cookie के expires फ़ील्ड पर अकेले भरोसा न करें। यह बताता है कि ब्राउज़र को cookie भेजना कब बंद करना चाहिए, जो यह नहीं है कि सर्वर उसे कब स्वीकार करना बंद करता है। सर्वर-साइड रद्दीकरण तब तक अदृश्य रहता है जब तक आप पूछें नहीं। फ़िक्स्चर की revoke कॉल ठीक यही स्थिति है: cookie अभी भी मौजूद और सही आकार का था, और सर्वर ने 401 दिया।
अपने आप दोबारा ऑथेंटिकेट करना
अपने आप दोबारा ऑथेंटिकेशन एक छोटी स्टेट मशीन है: पहचानें, फिर लॉगिन करें, सेव स्टेट रिफ़्रेश करें, फेल स्टेप एक बार फिर चलाएँ, और वेरिफ़ाई करें। सीमा मायने रखती है। जो वर्कफ़्लो चुपचाप लूप में दोबारा ऑथेंटिकेट करता है वह गलत पासवर्ड, अकाउंट लॉकआउट, या बदला लॉगिन पेज छिपा सकता है, और ऐसा करते हुए ट्रैफ़िक भी बनाता रहेगा।
async function withSession(page, context, task) {
if (!(await sessionIsAlive(context))) {
await loginAndSaveState(context, page); // refresh file after login
}
try {
return await task();
} catch (error) {
if (!(await sessionIsAlive(context))) {
await loginAndSaveState(context, page); // one retry, then fail loudly
return await task();
}
throw error;
}
}फ़िक्स्चर में डिटेक्टर ने 401 देखा, फिर लॉगिन और वेरिफ़िकेशन 99 मिलीसेकंड में पूरे हुए, और रिफ़्रेश स्टेट फ़ाइल में फिर ठीक एक सत्र cookie था। रन सुरक्षित डैशबोर्ड पर खत्म हुआ, टेबल दिख रही थी और तीन पंक्तियाँ रेंडर हुईं। जो दोबारा ऑथेंटिकेशन इन तीन पुष्टियों के बिना खत्म होता है, वह पूरा नहीं है।
अगर कई worker एक स्टेट फ़ाइल साझा करते हैं, तो सभी एक ही पल में एक्सपायरी देख सकते हैं और फिर लॉगिन की होड़ लगा सकते हैं। इलाज single-flight समन्वय है: पहला worker फ़ाइल रिफ़्रेश करे और बाकी प्रतीक्षा करें, या हर worker अपनी कॉपी रिफ़्रेश करे। यांत्रिकी वही है जो सत्र बने रहने की समस्याएँ तब दिखती हैं जब कई एजेंट एक ही ब्राउज़र प्रोफ़ाइल के विरुद्ध चलते हैं।
कई अकाउंट और समानांतर रन
आइसोलेशन कॉन्टेक्स्ट के हिसाब से है, इसलिए नियम है एक अकाउंट या भूमिका पर एक स्टोरेज फ़ाइल, एक worker पर एक कॉन्टेक्स्ट, और कोई साझा बदलने योग्य सत्र नहीं। फ़िक्स्चर में दो समानांतर लॉगिन ने दो अलग सत्र cookies दीं, दोनों जांच ने उसी मिलीसेकंड में 200 लौटाया, और कोई कॉन्टेक्स्ट दूसरे का सत्र नहीं देख सका। यही गुण जानबूझकर बचाना है, क्योंकि टूटने पर फेल मोड सूक्ष्म होता है: दो अकाउंट एक दूसरे का स्टेट ओवरराइट कर देते हैं और टेस्ट गलत यूज़र के लिए पास हो जाता है।
यही नियम असली ब्राउज़र में दिखता है। दो Space दो context हैं: एक नए टैब पर idle रह सकता है, दूसरा signed-in Airbnb सत्र रख सकता है, बिना उस तरह कुकी साझा किए जैसे एक headed विंडो करेगी। मुद्दा isolation है। ओवरव्यू सिर्फ़ दोनों को एक साथ दिखाने का तरीका है।
यह जाँचना कि ऑथेंटिकेशन वाकई लागू हुआ
वेरिफ़िकेशन तीन जाँचें हैं, और किसी को भी छोड़ना यही है जिससे वर्कफ़्लो चुपचाप टूटा रहता है। पहली जाँच सकारात्मक है: वह एलिमेंट मौजूद है जो केवल लॉगिन के बाद होता है। दूसरी नकारात्मक है: लॉगिन फ़ॉर्म अनुपस्थित है, इसलिए जो पेज संयोग से दोनों रखता है उसे स्वीकार नहीं किया जाता। तीसरी डेटा जाँच है जो बासी या कैश पेज पर फेल हो जाए, जैसे कोई मान जो रन के बीच बदलना चाहिए।
await page.waitForSelector("#revenue-table"); // positive
await expect(page.locator("#login-form")).toHaveCount(0); // negative
const probe = await context.request.get("/api/summary"); // data
assert.equal(probe.status(), 200);
assert.ok((await probe.json()).q3Revenue);फ़िक्स्चर के रीयूज़ रन में तीनों पास हुईं: टेबल दिख रही थी, लॉगिन फ़ॉर्म की गिनती शून्य थी, और JSON पेलोड में अपेक्षित फ़ील्ड था। तीनों मिलकर कुछ मिलीसेकंड लेती हैं, और काम करते सत्र तथा टूटे सत्र के फ़र्क को अनुमान से तथ्य बना देती हैं। जो रन अभी भी गड़बड़ करते हैं उनके लिए और डिबग तकनीक Playwright डिबग गाइड में है, और बेस्ट प्रैक्टिसेज़ पेज आसपास की आदतें कवर करता है, जिनमें यह भी है कि कौन से wait लिखने लायक हैं।
जब सत्र आपके असली ब्राउज़र का हो
Playwright storageState फ़ाइल वह चीज़ है जिसका आप मालिक हैं। यही सही औज़ार है जब अकाउंट फ़िक्स्चर हो, पासवर्ड CI secrets में हो, और मशीन पर कोई बैठा न हो। यही गलत औज़ार है जब लॉगिन आपका हो: SSO, हार्डवेयर कुंजी, पुश प्रॉम्प्ट, वह सत्र जिसे आप रोज़ के Chrome में पहले से गर्म रखते हैं। उस स्थिति में काम लॉगिन को फिर से बनाना नहीं है। काम उस ब्राउज़र को उधार लेना है जिसमें वह पहले से है।
ego (lite) वही उधार है। एक एजेंट आपके पहले से इस्तेमाल वाले साइन-इन टैब को खोल सकता है, ऐसे Space में काम जारी रख सकता है जो आपका माउस न छीने, और रुक सकता है जब दूसरे फ़ैक्टर या भुगतान पुष्टि को आपकी ज़रूरत हो। सत्र डिस्क पर JSON फ़ाइल कभी नहीं बनता। यही मुद्दा है: निजी लॉगिन ब्राउज़र में रहना चाहिए, storageState पाथ से नहीं गुज़रना चाहिए जिसे CI बाद में गलती से commit कर दे।
दोनों औज़ार अलग रखें। बिना निगरानी वाले टेस्ट अकाउंट storageState पर रहते हैं, जैसा Playwright ऑथ गाइड बताता है। निजी डैशबोर्ड दिख रहे ब्राउज़र में रहते हैं। ego (lite) MFA पर क्लिक नहीं करता, भुगतान कन्फ़र्म नहीं करता, और क्रेडेंशियल नहीं इकट्ठा करता; ये रुकावटें Space दस्तावेज़ और क्विक स्टार्ट में दर्ज हैं। मौजूदा प्रोडक्ट वर्शन 0.5.0.32 है (changelog, 2026-09-12)। दोबारा जाँचें changelog और GitHub रिपॉज़िटरी को नए बिल्ड का हवाला देने से पहले।
FAQ
storageState सेव करने के बाद भी Playwright लॉगिन पेज पर क्यों पहुँच जाता है?
storageState के बाद Playwright लॉगिन पेज पर तब पहुँचता है जब फ़ाइल बहुत जल्दी सेव हुई, कॉन्टेक्स्ट ने उसे कभी लोड नहीं किया, या सर्वर ने cookie रद्द कर दी। पहले फ़ाइल की cookies जाँचें, फिर कॉन्टेक्स्ट विकल्प। अगर दोनों सही लगें, तो इसे मरे सत्र मानें, नेविगेशन बग नहीं।
क्या सत्र cookies storageState में बचती हैं?
हाँ। फ़ाइल cookies रिकॉर्ड करती है चाहे उनकी एक्सपायरी हो या न हो, साथ में origin के हिसाब से localStorage। जो नहीं बचता वह वह है जो ब्राउज़र इस संरचना के बाहर रखता है: IndexedDB, session storage, कैश, और service workers।
सेव किया Playwright लॉगिन कितने समय चलता है?
जब तक सर्वर सत्र स्वीकार करता रहे, और यह फ़ैसला सर्वर का है जिसे वह कभी भी पलट सकता है। Cookie की एक्सपायरी तारीख ऊपरी सीमा है, वादा नहीं। किसी भी लंबे समय वाली स्टेट फ़ाइल को बासी मानें जब तक जांच कुछ और न कहे।
क्या समानांतर worker एक storageState फ़ाइल साझा कर सकते हैं?
वे उसे पढ़ सकते हैं, और हर worker का कॉन्टेक्स्ट अलग रहेगा। समस्या तब आती है जब एक worker फिर लॉगिन के बाद फ़ाइल रिफ़्रेश करे और दूसरा रन के बीच में हो। या हर worker को अपनी कॉपी दें, या रिफ़्रेश को सीरियलाइज़ करें ताकि एक समय में केवल एक लॉगिन हो।
Playwright में OAuth या SSO से ऑथेंटिकेट कैसे करें?
पूरी रीडायरेक्ट श्रृंखला एक बार पूरे करें, ऐसे कॉन्टेक्स्ट में जो आइडेंटिटी प्रोवाइडर की cookies रखे, और स्टेट तभी सेव करें जब ऐप का अंतिम URL पहुँच जाए। अगर प्रोवाइडर को इंटरैक्टिव कदम चाहिए, उसे उसी रन में एक बार हाथ से करें और बाद में बने स्टेट का फिर से उपयोग करें।
MFA और एक-बार कोड का कैसे व्यवहार करें?
दूसरे फ़ैक्टर को स्टोर किए कोड से ऑटोमेट करके नहीं। ईमानदार पैटर्न एक बार का मानवीय कदम है जिसका परिणाम सेव सत्र है, या वह सत्र जो आपके ब्राउज़र में पहले से ऑथेंटिकेटेड था। OTP सीक्रेट या SMS कोड को स्टोरेज फ़ाइल के पास रखना सुरक्षा नियंत्रण को देनदारी बना देता है।
क्या storageState को वर्शन कंट्रोल में commit करना सुरक्षित है?
नहीं। फ़ाइल में जीवित सत्र cookies हैं। इसे वर्किंग डायरेक्टरी में रखें, git में ignore करें, और CI में secret store से डालें। अगर कभी commit हो चुका है, सत्र को लीक मानें और रद्द करें।
यह जानबूझकर कैसे टेस्ट करें कि ऑटोमेशन खत्म सत्र संभालता है?
ऐसा टेस्ट हुक जोड़ें जो सत्र को सर्वर साइड अमान्य करे, जैसे फ़िक्स्चर का revoke एंडपॉइंट करता है, और उसके विरुद्ध रीयूज़ पाथ चलाएँ। रीडायरेक्ट, जांच से 401, और रिकवरी का assert करें। वह एक टेस्ट उसी कोड पाथ को कवर करता है जो वरना केवल प्रोडक्शन में चलता है।
अगर ऐप अपना टोकन IndexedDB में रखे तो?
storageState उसे नहीं ले जाएगा, इसलिए दो पाथ में से एक अपनाएँ: लॉगिन के बाद पेज स्क्रिप्ट से टोकन कैप्चर करें और रीयूज़ पर फिर डालें, या हर रन के अंदर उस API से ऑथेंटिकेट करें जो टोकन जारी करता है। पहला तेज़ है, दूसरा ऐप के अंदरूनी हिस्से से कम जुड़ा है।
क्या हर रन को स्टेट रीयूज़ करने के बजाय दोबारा ऑथेंटिकेट करना चाहिए?
खपने योग्य टेस्ट अकाउंट वाले CI के लिए हर रन पर दोबारा ऑथेंटिकेट करना ज़्यादा सुरक्षित डिफ़ॉल्ट है। जो जॉब स्थिर सत्र के विरुद्ध बार-बार चलता है, उसके लिए रीयूज़ प्लस जांच और सीमित फिर लॉगिन सस्ता और सोचने में आसान है। दोनों जायज़ हैं; बिना जाँच का रीयूज़ नहीं।
लॉगिन लोकल पर क्यों चलता है और CI में क्यों फेल होता है?
आमतौर पर इसलिए कि CI में स्टेट फ़ाइल गायब या पुरानी है, घड़ी अलग है, या लॉगिन पेज नए IP को अलग वैरिएंट देता है। उसी headless सेटिंग, viewport और स्टोरेज फ़ाइल से दोहराएँ, और सूट चलने से पहले सत्र की जांच करें। फेल अक्सर पर्यावरण का होता है, कोड का फ़र्क नहीं।
क्या एक storageState फ़ाइल दो अकाउंट चला सकती है?
नहीं, और उन्हें मिलाने की कोशिशें अक्सर वही cookie रखती हैं जो आखिर में लिखी गई। हर अकाउंट या भूमिका के लिए एक फ़ाइल रखें, उसे उसी पहचान के नाम पर रखें जिससे वह जुड़ी है, और हर कॉन्टेक्स्ट को सही वाली दें।