محدود کردن پخش ویدیو به دامنه و تست پیش از فروش دوره
دامنهٔ اصلی، زیر‌دامنهٔ آموزشی و محیط آزمایشی را درست تعریف کنید و محدودیت محل پخش را جدا از مجوز حساب هنرجو بسنجید.
برای محدود کردن پخش ویدیو به دامنه، ابتدا نشانی واقعی صفحهٔ درس را از نگاه مرورگر مشخص کنید. سپس یک ویدیوی آزمایشی را روی همان نشانی و یک دامنهٔ تحت کنترل خودتان که در فهرست مجاز نیست امتحان کنید. اگر درس خریدنی است، در دامنهٔ مجاز هم یک حساب با خرید و یک حساب بدون خرید را جدا آزمایش کنید. به این ترتیب معلوم می‌شود محل نمایش پلیر کنترل می‌شود و حق مشاهدهٔ هنرجو نیز در مسیر خودش بررسی شده است.
برای وردپرس یا سایت‌هایی که چند زیر‌دامنه دارند، یک بار مسیر را از لینک خرید تا نشانی نهایی درس طی کنید. ممکن است کاربر از دامنهٔ اصلی شروع کند و پس از ورود به زیر‌دامنهٔ آموزش برود. تنظیمات پخش باید به نشانی‌ای مربوط باشند که پلیر واقعاً در آن قرار می‌گیرد. وقتی پلیر در یک قاب تو در تو جاسازی شده، صفحهٔ درس و قاب‌های بالاتر هم می‌توانند در تصمیم مرورگر نقش داشته باشند. راهنمای پخش دوره در وردپرس
فهرست نشانی‌های مجاز را از روی مسیر واقعی درس بسازید
برای شروع یک پروندهٔ ساده باز کنید و در آن دامنهٔ اصلی، زیر‌دامنهٔ آموزش، محیط آزمایشی و هر آدرسی را که بعد از ورود در نوار مرورگر دیده می‌شود بنویسید. به تغییرمسیرها توجه کنید. برای نمونه اگر نسخهٔ دارای www کاربران را به نسخهٔ بدون www می‌فرستد، آدرس اول راه ورود است و دومی می‌تواند محل واقعی صفحهٔ درس باشد. اگر پلیر قبل از تغییرمسیر اصلاً اجرا نمی‌شود، این دو نشانی نقش یکسانی ندارند.
در یک نمونهٔ فرضی، نشانی معرفی دوره example.com است، ورود هنرجو در accounts.example.com انجام می‌شود و کلاس ضبط‌شده در learn.example.com باز می‌شود. اگر ویدیو فقط در صفحهٔ سوم جاسازی شده، ابتدا همان میزبان را در فهرست بررسی کنید. در صفحهٔ حساب یا صفحهٔ معرفی شاید اصلاً پلیر وجود نداشته باشد. اگر بعداً برای درس نمونه در صفحهٔ معرفی هم ویدیو قرار می‌دهید، با توجه به سیاست دسترسی آن محتوا یک آزمون جدا انجام دهید. ممکن است تنظیم مربوط به هر ویدیو، پوشه یا حساب جدا باشد.
منظور از «دامنه» در هر سرویس الزاماً قالب ورودی یکسان ندارد. گاهی پنل نام میزبان می‌خواهد. گاهی مستندات از مبدأ صفحه حرف می‌زنند که طرح نشانی، میزبان و در صورت تفاوت، درگاه را در نظر می‌گیرد. فرم را با نمونه‌های رسمی همان ارائه‌دهنده پر کنید. اگر وارد کردن مسیر صفحه، ستاره، زیر‌دامنه یا پورت در مستندات توضیح داده نشده، فرض نکنید همهٔ آن‌ها کار خواهند کرد. در دفتر آزمون ورودی دقیق و نتیجهٔ مرورگر را کنار هم بگذارید.
برای مدیریت فهرست، کنار هر نشانی یک دلیل و یک مسئول بنویسید. دامنهٔ تولید برای درس‌های واقعی است. محیط آزمایشی برای کنترل تغییرات قبل از فروش است. آدرس پیش‌نمایش تیم طراحی ممکن است فقط چند روز لازم باشد. وقتی کاری تمام شد، بررسی کنید آیا آن نشانی هنوز باید در فهرست بماند. وجود فهرست کوتاه با دلیل روشن، پیدا کردن تنظیم اشتباه را در زمان خطا آسان‌تر می‌کند.
محدودیت محل پخش و مجوز خرید دو لایهٔ جدا هستند
فهرست دامنهٔ مجاز به این پرسش پاسخ می‌دهد که یک ویدیو یا پلیر در چه محل‌هایی می‌تواند نمایش داده شود. مجوز خرید به این پرسش پاسخ می‌دهد که کدام حساب اجازه دارد درس مشخصی را ببیند. وقتی هر دو لایه در کارند، باز شدن صفحهٔ درس روی دامنهٔ درست می‌تواند شرط اول را بگذراند و پخش همچنان به دلیل نبود خرید رد شود. این رفتار در دورهٔ پولی طبیعی است و باید برای پشتیبان قابل توضیح باشد. کنترل دسترسی و محل پخش در فاکسیمون
مثال معکوس را هم بررسی کنید. هنرجوی نمونه خرید دارد، ولی از یک صفحهٔ غیرمجاز وارد شده است. سیاست مجموعه ممکن است جلوی جاسازی در آن صفحه را بگیرد. در این صورت تکرار خرید مشکل را حل نمی‌کند. پیام مناسب باید او را به نشانی درست دوره برگرداند. اگر از راهنمای ورود یا لینک دعوت استفاده می‌کنید، نشانی معتبر را در پیام مشخص کنید تا پشتیبان مجبور نباشد حدس بزند هنرجو از چه صفحه‌ای به پخش رسیده است.
در این آزمون، نمایش قاب، دیده شدن تصویر جلد و پخش واقعی را سه مشاهدهٔ جدا بنویسید. گاهی قاب باز می‌شود و تصویر جلد هم دیده می‌شود ولی درخواست رسانه پس از بررسی حساب رد می‌شود. گاهی مرورگر از اول اجازهٔ باز شدن قاب را نمی‌دهد. گاهی صفحهٔ درس عمومی است و فقط محتوای پولی محافظت می‌شود. اگر این تفاوت‌ها را در گزارش ننویسید، نتیجهٔ «صفحه باز شد» می‌تواند به‌اشتباه به معنی «درس بدون خرید پخش شد» خوانده شود. حدود حفاظت از ویدیوی آموزشی
خطای جاسازی را از CORS و درخواست رسانه جدا کنید
در بعضی پیاده‌سازی‌ها، صفحهٔ پلیر در یک قاب قرار می‌گیرد. سیاست قاب‌بندی مرورگر می‌تواند تعیین کند چه صفحاتی حق دارند یک منبع را در قاب خود قرار دهند. برای نمونه دستور frame-ancestors در سیاست امنیت محتوا، والدهای مجاز را مشخص می‌کند. در قاب تو در تو، مرورگر فقط به والد نزدیک نگاه نمی‌کند و همهٔ قاب‌های والد باید با سیاست مربوط سازگار باشند. اگر طرح شما از قاب استفاده نمی‌کند، نوع کنترل را از مستندات همان پلیر مشخص کنید. مرجع MDN برای frame-ancestors
CORS به مرورگر می‌گوید یک صفحه در چه شرایطی می‌تواند پاسخ یک درخواست میان‌مبدأ را در اختیار کد خود قرار دهد. این سازوکار با مجوز خرید یا محدودیت جاسازی یکی نیست. پیام CORS در ابزار توسعه ممکن است به درخواست فایل، فهرست رسانه یا API مربوط باشد، در حالی که قاب به‌درستی باز شده است. قبل از تغییر سیاست دامنه، نام درخواست و مرحله‌ای را که خطا در آن رخ می‌دهد مشخص کنید. از روی یک پیام عمومی مرورگر تصمیم نگیرید همهٔ محدودیت‌ها را باز کنید. راهنمای CORS در MDN
اگر مرورگر خطای مربوط به قاب را نشان می‌دهد، نشانی صفحهٔ والد و زنجیرهٔ قاب‌ها را به تیم فنی بدهید. اگر قاب باز است و خطا پس از فشردن پخش رخ می‌دهد، زمان تلاش، وضعیت حساب آزمایشی و نوع درخواست را ثبت کنید. ممکن است درخواست برای مجوز یا رسانه باشد و نتیجهٔ هرکدام دلیل متفاوتی داشته باشد. در مستندات تیم می‌توانید یک ستون برای «محل خطا» بگذارید که فقط یکی از صفحه، قاب، مجوز یا پخش را نشان دهد. این ستون از ارجاع همهٔ خطاها به یک تیم جلوگیری می‌کند.
در برخی سرویس‌ها، تنظیمات شبکهٔ تحویل، اعتبار نشست یا محدودیت محل نمایش در سطح سرویس اعمال می‌شود. بررسی کنید محدودیتی که در پنل می‌بینید در کدام درخواست سنجیده می‌شود. برای آزمایش ایمن، فقط روی ویدیوی خودتان و صفحات تحت کنترل سازمان آزمایش کنید. به یک آزمایش مستقیم از آدرس رسانه یا به تغییر دستی هدرهای مرورگر تکیه نکنید. رفتار واقعی همان مرورگر و همان صفحه را ثبت کنید و در صورت نیاز از ارائه‌دهنده دربارهٔ روش پشتیبانی‌شده سؤال کنید. اتصال پلیر و ابزارها به سایت
یک ویدیو و چهار صفحه برای پایلوت آماده کنید
برای پایلوت، یک فیلم کوتاه با محتوای ساختگی انتخاب کنید. صفحهٔ اول روی محل نهایی درس است. صفحهٔ دوم محیط آزمایشی است که قرار است تا زمان مشخصی مجاز باشد. صفحهٔ سوم یک نشانی تحت کنترل شماست که عمداً در فهرست مجاز قرار نگرفته. صفحهٔ چهارم می‌تواند نشانی اولیه‌ای باشد که کاربر را به دامنهٔ اصلی یا زیر‌دامنهٔ نهایی می‌فرستد. هر صفحه را با یک مرورگر عادی باز کنید و نشانی نهایی را بنویسید. سپس با حساب نمونه و یک حساب فاقد خرید آزمایش کنید.
| وضعیت آزمایش | انتظار اولیه | چه چیزی ثبت شود |
|---|---|---|
| دامنهٔ درس و حساب مجاز | پخش درس درست | نشانی نهایی، دستگاه و شروع پخش |
| دامنهٔ درس و حساب بدون خرید | محتوای پولی پخش نشود | ظاهر صفحه، پیام و نتیجهٔ تلاش |
| دامنهٔ آزمایشی مجاز و حساب نمونه | رفتار مطابق تنظیم مرحله | نام محیط و دامنهٔ تأییدشده |
| دامنهٔ خارج از فهرست | جاسازی یا پخش طبق سیاست رد شود | مرحلهٔ رد و پیام مرورگر |
| ورود با نسخهٔ دیگری از آدرس | نتیجه طبق نشانی پس از تغییرمسیر | مسیر شروع، مقصد و زمان پخش |
| دامنهٔ مجاز و مجوز منقضی | صدور مجوز تازه طبق سیاست متوقف شود | تفاوت درخواست تازه و نشست قبلی |
در آزمایش صفحهٔ غیرمجاز، یک ویدیوی آزاد کنار ویدیوی محدود قرار دهید. اگر هیچ‌کدام کار نمی‌کنند، پیش از نتیجه‌گیری شبکه یا عملکرد کلی پلیر را بررسی کنید. اگر فقط ویدیوی محدود در همان صفحه شکست می‌خورد، شاهد بهتری دارید که سیاست محل نمایش یا دسترسی نقش دارد. حساب و فایل آزمون را در دو حالت ثابت نگه دارید. برای نمونه اگر در صفحهٔ مجاز از حساب مدرس و در صفحهٔ غیرمجاز از حساب بدون خرید استفاده کنید، دو متغیر را با هم تغییر داده‌اید و علت روشن نمی‌ماند.
مرحلهٔ بعد را با گوشی و مرورگر عادی هنرجو انجام دهید. مسیر ورود را همان‌طور طی کنید که کاربر از پیام خرید یا صفحهٔ حساب آغاز می‌کند. برخی محیط‌ها می‌توانند در صفحهٔ دسکتاپ آدرس یکسانی نشان دهند اما در گوشی از مسیر دیگری استفاده کنند. اگر نسخهٔ موبایل و دسکتاپ واقعاً در یک نشانی‌اند، همچنان رفتار قاب و پیام مجوز را ثبت کنید. در نهایت فقط نتیجه‌ای را به آموزشگاه گزارش کنید که در محیط واقعی خودتان تکرار شده است.
زیر‌دامنه و آدرس پیش‌نمایش را در طول عمر پروژه مدیریت کنید
هنگام طراحی سایت ممکن است نشانی‌های موقتی برای پیش‌نمایش ایجاد شوند. به هر نشانی تاریخ پایان بدهید و به‌جای وارد کردن طیف بزرگی از زیردامنه‌ها، قالب محدود سازگار با مستندات را به کار ببرید. اگر برای آزمون در یک پیش‌نمایش لازم است دامنه‌ای مجاز شود، ابتدا محتوای ساختگی و حساب نمونه را انتخاب کنید. پس از اتمام کار بررسی کنید که تولید همچنان درست پخش می‌کند و آدرس آزمایشی دیگر به همان ویدیو دسترسی ندارد.
برای انتقال سایت از یک میزبان به میزبان دیگر، جدول کوچکی از نشانی‌های قدیم و جدید تهیه کنید. قبل از تغییر عمومی، یک درس نمونه را روی مقصد جدید بررسی کنید. اگر مدتی هر دو آدرس فعال خواهند بود، زمان این هم‌پوشانی را در فهرست ثبت کنید. پس از پایان انتقال، از طریق مسیر واقعی هنرجو تأیید کنید که آدرس قدیم به جای درست هدایت می‌شود و پلیر در صفحهٔ جدید کار می‌کند. اگر نشانی حساب یا مسیر درس تغییر کرده، راهنمای خرید و پیام‌های پشتیبانی را هم هم‌زمان بازبینی کنید. پشتیبان‌گیری از فایل‌های دوره
در وردپرس، پیش‌نمایش مطلب و صفحهٔ منتشرشده گاهی نقش متفاوتی دارند. پیش‌نمایش برای حساب دارای اختیار باز می‌شود و ممکن است در نشانی یا ساختار قاب متفاوتی قرار گیرد. تست آن برای تیم طراحی مفید است. قبل از فروش، همان درس را از صفحهٔ منتشرشده و با حساب عادی هنرجو امتحان کنید. اگر افزونه کش یا صفحه‌ساز تغییر می‌کند، یک بار پس از پاک شدن کش معمول و یک بار در مرورگری که صفحه را قبلاً دیده بررسی کنید. نتیجه را بدون قرار دادن کلید یا اطلاعات خرید واقعی در گزارش ثبت کنید.
از روی الگوی خطا تصمیم بگیرید چه چیزی را اصلاح کنید
اگر پخش در همهٔ دامنه‌ها شکست می‌خورد، ابتدا فایل نمونه، وضعیت سرویس و سلامت درخواست عمومی را بررسی کنید. اگر فقط دامنهٔ اصلی خطا دارد و محیط آزمایشی کار می‌کند، تفاوت نشانی نهایی، سیاست قاب و تنظیمات نسخهٔ تولید را کنار هم بگذارید. اگر فقط حساب فاقد خرید رد می‌شود و حساب مجاز درست پخش می‌کند، این می‌تواند نشانهٔ عملکرد طبیعی مجوز باشد. در این حالت پیام را از دید هنرجو بخوانید تا روشن باشد برای دسترسی چه اقدامی لازم است.
یک نمونهٔ تشخیص فرضی را در نظر بگیرید. تیم اعلام می‌کند روی صفحهٔ درس هیچ قاب پخشی دیده نمی‌شود، اما همان ویدیو در پیش‌نمایش میزبان قابل پخش است. ابتدا نشانی محل جاسازی و پیغام مرورگر را بررسی کنید. اگر پیام دربارهٔ والد غیرمجاز است، نوع قاب و میزبان واقعی صفحه را ثبت کنید. حالا نمونهٔ دوم را در نظر بگیرید که قاب و جلد دیده می‌شوند ولی پس از ورود به پخش خطا می‌آید. در این وضعیت وضعیت خرید، اعتبار نشست و درخواست رسانه را بررسی کنید. ظاهر مشابه صفحه نباید موجب شود هر دو گزارش به یک تنظیم ارجاع داده شوند.
یک نمونهٔ سوم زمانی رخ می‌دهد که کاربران از پیام خرید وارد نسخهٔ قدیمی آدرس می‌شوند و پس از تغییرمسیر به صفحهٔ دیگری می‌رسند. برای حل آن، پیام خرید را از یک حساب آزمایشی باز کنید و همهٔ مقصدهای دیده‌شده را در برگه بنویسید. ممکن است اصلاح نشانی پیام کافی باشد یا لازم باشد تنظیم دامنهٔ مقصد را هم بررسی کنید. بعد از اصلاح، مسیر شروع از پیام قدیمی و مسیر ورود مستقیم را هر دو امتحان کنید. نتیجهٔ هر مسیر را کنار زمان آزمون ثبت کنید تا تیم پشتیبانی بتواند مورد گزارش‌شده را دوباره ببیند.
برگهٔ تحویل به پشتیبان را با نتیجهٔ آزمایش تکمیل کنید
تنظیمات صفحهٔ والد را در کنار پلیر ثبت کنید
قبل از تغییر، از تنظیمات فعلی یک یادداشت قابل بازگشت تهیه کنید. نام محیط، فهرست نشانی‌های مجاز، نسخهٔ پلیر و آخرین تاریخ تغییر را بنویسید. اگر پخش در صفحهٔ سازندهٔ دوره درست است اما در سایت نهایی شکست می‌خورد، تفاوت این دو مسیر را روی کاغذ بیاورید. ممکن است در یک مسیر پلیر مستقیماً باز شده باشد و در دیگری داخل یک قاب در صفحهٔ فروش قرار بگیرد. نتیجهٔ باز کردن مستقیم پلیر، فقط همان مسیر مستقیم را بررسی می‌کند. برای گزارش به تیم، صفحهٔ واقعی هنرجو را مبنا قرار دهید.
برای نمونه یک آموزشگاه در صفحهٔ دوره از یک ماژول آماده استفاده می‌کند. ماژول درون صفحه یک قاب می‌سازد و بعد پلیر درون آن قرار می‌گیرد. در پیش‌نمایش مستقل، پلیر کار می‌کند. در مسیر هنرجو، صفحهٔ بیرونی و قاب میانی هر دو در زنجیره هستند. هنگام بررسی، نشانی هر دو والد را ثبت کنید و از تیم مسئول بپرسید کدام سیاست و از کدام پاسخ آمده است. در صورت نیاز به تغییر فهرست، فقط نشانی‌هایی را اضافه کنید که در مسیر کنترل‌شده و ضروری هستند. سپس همان ساختار را در مرورگر عادی، بدون دسترسی مدیر، دوباره اجرا کنید.
این نقشه برای تعیین مسئولیت هم مفید است. اگر سیاست در پاسخ صفحهٔ پلیر فرستاده می‌شود، ممکن است تیم رسانه مسئول تغییر آن باشد. اگر سایت اصلی ساختن قاب یا فراخوانی یک منبع را محدود کرده، تیم سایت باید آن بخش را بررسی کند. قبل از درخواست تغییر، مشخص کنید کدام پاسخ پیام را ایجاد کرده است. این تفاوت می‌تواند از رفت و برگشت میان دو تیم جلوگیری کند و زمان رفع خطا در روز عرضه را کاهش دهد.
پس از تغییر تنظیمات آزمون کنترل انجام دهید
یک تغییر را در هر نوبت اعمال کنید. ابتدا فقط مسیر اصلی تولید را با فایل آزمایشی و حساب دارای خرید بررسی کنید. بعد همان صفحه را با حساب بدون خرید باز کنید و در پایان سراغ صفحهٔ خارج از فهرست بروید. اگر هم‌زمان آدرس صفحه، افزونه و تنظیمات مجوز را عوض کنید، پس از رفع خطا مشخص نمی‌شود کدام تغییر لازم بوده است. ثبت هر مرحله با تاریخ و نتیجه به تیم اجازه می‌دهد تغییر را در صورت نیاز برگرداند یا در محیط دیگر تکرار کند.
اگر سایت از کش استفاده می‌کند، ابتدا صفحه را در پنجرهٔ تازه باز کنید و یک بار از مسیر عادی هنرجو وارد شوید. سپس در مرورگری که قبل از تغییر صفحه را دیده همان آزمایش را انجام دهید. اختلاف میان این دو می‌تواند به نسخهٔ قدیمی پاسخ یا تنظیمات صفحه مربوط باشد. کش مرورگر کاربر را به‌عنوان راه‌حل دائمی در نظر نگیرید. ابتدا منشأ پاسخ قدیمی را بیابید و ببینید چه زمانی به‌روزرسانی می‌شود. بعد از پایان زمان یا اعمال اصلاح، از یک دستگاه دیگر هم نتیجه را بگیرید تا موفقیت به یک نشست خاص وابسته نماند.
یک مسئلهٔ رایج در زمان انتشار این است که محیط آزمایشی از تنظیمات متفاوتی نسبت به تولید استفاده می‌کند. به جای انتقال همهٔ نشانی‌های تست به تولید، مورد لازم را با نام محیط جدا نگه دارید. اگر یک شریک آموزشی دامنهٔ مستقلی دارد، ابتدا با یک ویدیوی نمونه و کاربران همان شریک آزمون کنید. دسترسی گروه‌های دیگر نباید از آزمون آن دامنه اثر بگیرد. پس از اتمام همکاری، رفتار مورد انتظار برای صفحهٔ شریک و صفحهٔ اصلی را دوباره بررسی کنید و فهرست را به وضعیت مورد نیاز برگردانید.
نتیجه را با یک گزارش قابل تکرار تحویل دهید
در پایان از پشتیبان بخواهید بدون حضور توسعه‌دهنده یک گزارش نمونه را بخواند و بگوید به کدام تیم ارجاع می‌دهد. برای نمونه «صفحهٔ درس باز می‌شود، قاب پخش روی دامنهٔ جدید دیده نمی‌شود و حساب نمونه در نشانی قدیمی هنوز پخش دارد». این گزارش باید نشانی مقصد و مرحلهٔ شکست را مشخص کند. اگر پشتیبان نمی‌تواند از آن تفاوت خطای دامنه و خطای حساب را بفهمد، برگه را کامل کنید. هدف از گزارش این است که فرد دیگری بتواند همان حالت را بازتولید کند، بدون اینکه اطلاعات پرداخت یا دسترسی خصوصی هنرجو را درخواست کند.
پایان کار را با یک آزمون کنترل بعد از انتشار مشخص کنید. یک نفر از پیام خرید به درس برسد، یک نفر در همان صفحه بدون مجوز تلاش کند و یک نفر صفحهٔ آزمایشی خارج از فهرست را باز کند. زمان، دستگاه و نتیجهٔ هر سه را ثبت کنید. اگر فروش به چند دامنه گسترش یافت، از همین الگو برای نشانی تازه استفاده کنید. این برگه کمک می‌کند تغییر دامنه، انتشار صفحهٔ جدید یا نصب نسخهٔ تازهٔ پلیر بدون از دست رفتن نتیجهٔ آزمون قبلی بررسی شود.
در برگهٔ تحویل، نشانی‌های مجاز، تاریخ آزمون، مرورگر، نوع حساب و شناسهٔ آزمایشی درس را نگه دارید. برای هر حالت بنویسید چه مرحله‌ای رد شد و کاربر چه پیامی دید. دادهٔ محرمانه یا نشانی دارای مجوز موقت را در تیکت عمومی قرار ندهید. اگر ارائه‌دهنده به اطلاعات بیشتر نیاز دارد، از روش رسمی گزارش یا ابزار امن همان سرویس استفاده کنید. برای پاسخ اول به هنرجو، یک لینک معتبر به صفحهٔ ورود و یک قدم واضح کافی است.
زمان بازبینی بعدی را هم کنار برگه بنویسید. تغییر دامنه، جابه‌جایی صفحهٔ درس و ارتقای پلیر سه موقعیتی هستند که ارزش تکرار آزمون دارند. مسئول انتشار می‌تواند قبل از هرکدام همان سه مسیر اصلی را اجرا کند و نتیجه را به گزارش قبلی اضافه کند. اگر رفتار تازه با نتیجهٔ قبلی فرق دارد، نخست اختلاف تنظیمات و نشانی واقعی صفحه را بررسی کنید تا علت تغییر مشخص شود.
برای روز فروش، یک معیار توقف داشته باشید. اگر دامنهٔ خارج از فهرست همان ویدیو را خلاف سیاست تعریف‌شده پخش می‌کند یا حساب بدون خرید در دامنهٔ مجاز به درس پولی می‌رسد، انتشار را تا فهم علت به همان نمونه محدود کنید. اگر مشکل فقط به یک آدرس قدیمی مربوط است، مسیر جدید را با هنرجوی آزمایشی تأیید کنید و سپس پیام‌ها و پیوندها را اصلاح کنید. بعد از هر تغییر، یک بار مسیر درست خرید و یک بار مسیر رد دسترسی را دوباره طی کنید. این دو آزمون به شما نشان می‌دهند هم حفاظت حفظ شده و هم دسترسی هنرجوی مجاز برقرار مانده است. راهنمای ارائه و حفاظت ویدیوی آموزشی