بهترین شیوه های مجوزهای وب

Marian Harbach

Thomas Steiner

درخواست‌های مجوز مکانیسم اصلی وب برای محافظت از قابلیت‌های قدرتمندی هستند که به طور بالقوه برای حریم خصوصی و امنیت کاربران خطرناک هستند. هدف مرورگرها با درخواست‌های مجوز، اطمینان از این است که کاربر قصد دارد به وب‌سایت درخواست‌کننده اجازه دسترسی به قابلیت مورد نظر را بدهد. درخواست‌های مجوز برای تعدادی از APIها از جمله ضبط رسانه (دوربین و میکروفون)، موقعیت جغرافیایی، دسترسی به فضای ذخیره‌سازی، MIDI و اعلان‌ها استفاده می‌شود (برای اطلاعات بیشتر به اسناد API مجوزها در MDN مراجعه کنید).

این راهنما بهترین روش‌ها را برای نمایش درخواست‌های مجوز به کاربران بر اساس آمار استفاده از Chrome و تحقیقات کاربر نشان می‌دهد. هنگام پیروی از این بهترین شیوه‌ها، کاربران باید با درخواست‌های غیرضروری کمتری مواجه شوند، که منجر به تصمیم‌گیری «بلاک» کمتری توسط توسعه‌دهندگان می‌شود. این مقاله با برخی از الگوهای کد برای کار با API های دارای مجوز و بهترین شیوه ها برای کمک به کاربران برای بازیابی از حالت مسدود شده به پایان می رسد.

ارائه بهترین شیوه ها

شما باید پس از تعامل با کاربر، در لحظه‌ای که کاربران می‌توانند بفهمند که چرا درخواست می‌کنید و چه سودی از این اجازه می‌گیرید، اجازه بخواهید. در صورت امکان، باید به کاربران اجازه دهید تا از یک ابزار جایگزین برای انجام همان عملکرد استفاده کنند. به عنوان یک دستورالعمل کلی، درخواست اجازه کمتر با انتخاب لحظاتی که با دقت درخواست می‌کنید، احتمال اینکه کاربران شما در حالت مسدود شده‌ای قرار بگیرند که بازیابی از آن سخت است، کاهش می‌یابد. بهترین شیوه های زیر جزئیات بیشتری را در مورد هر یک از این پیشنهادات ارائه می دهد.

هرگز در بارگذاری صفحه یا بدون تعامل کاربر سؤال نکنید

درخواست مجوز از کاربران برای بارگذاری صفحه، معادل درخواست از یک مشتری برای یک قطعه حساس از اطلاعات هنگام ورود به یک فروشگاه فیزیکی است. دیدن یک درخواست مجوز (احتمالاً در میان چندین درخواست دیگر برای ثبت نام در خبرنامه و رضایت کوکی) تجربه بسیار دردناکی است. کاربران متوجه نمی شوند که چرا از آنها سؤال می شود و چگونه سود می برند .

حتی اگر برنامه وب شما نمی تواند بدون دسترسی به یک قابلیت خاص کار کند، باید به کاربران فرصت دهید تا بفهمند چرا به آن نیاز است. به‌عنوان مثال، با پیش‌گفتار درخواست مجوز با درخواستی از خودتان که نیاز را توضیح می‌دهد و به کاربران امکان انتخاب می‌دهد (مثلاً، در صورت امکان، با ارائه ابزارهای جایگزین برای انجام همان عملکرد ). اگر نمی توانید لحظه ای بهتر از زمان بارگذاری صفحه برای درخواست اجازه فکر کنید، چند نمونه در ادامه این راهنما وجود دارد.

یک وضعیت بد مشابه برای درخواست مجوز، بدون تعامل قبلی با کاربر است (که به عنوان فعال سازی گذرا کاربر نیز شناخته می شود). تله متری کروم نشان می دهد که 77٪ از درخواست های مجوز در کروم دسکتاپ بدون چنین سیگنال بسیار ابتدایی از قصد کاربر نشان داده می شوند و در نتیجه تنها 12٪ از چنین درخواست هایی مجاز می شوند. پس از تعامل با کاربر، اجازه دهید نرخ ها تا 30٪ افزایش یابد. بنابراین، فقط پس از اینکه کاربر به شکلی با صفحه ارتباط برقرار کرد، اجازه بخواهید.

فقط زمانی بپرسید که کاربران بتوانند دلیل سوال شما را بفهمند

تصمیمات مجوز اغلب تصمیمات حریم خصوصی هستند. بر اساس چارچوب یکپارچگی زمینه‌ای ، ما می‌دانیم که تصمیم‌های مربوط به حریم خصوصی بسیار زمینه‌ای هستند. درک اینکه چرا دسترسی ضروری است را می توان یکی از جنبه های کلیدی این امر در نظر گرفت. بنابراین، شما فقط باید قابلیت هایی را درخواست کنید که برای ارائه ارزش به کاربران نیاز دارید (و در جایی که کاربران احتمالاً با شما موافق هستند که واقعاً ارزش دریافت خواهند کرد). علاوه بر این، باید در لحظه ای که برای کاربر مشخص است که چرا این قابلیت مفید است، اجازه بخواهید. هدف این است که درک زمینه استفاده را تا حد امکان برای کاربران خود آسان کنید.

تحقیقات کاربران ما نشان می‌دهد که کاربران زمانی که بفهمند چرا یک سایت درخواست دسترسی می‌کند و همچنین مزایایی را درک می‌کنند، به طور قابل‌توجهی به احتمال زیاد اجازه دسترسی را می‌دهند. همچنین متوجه شدیم که کاربران انتظار دارند ابتدا سایت‌های ناآشنا را کاوش کنند تا ارزشی را که می‌توانند در ازای اجازه دسترسی دریافت کنند، درک کنند. آنها اغلب در این مدت درخواست های مجوز را رد می کنند یا نادیده می گیرند. با مجوزهای یکباره، ممکن است ابتدا اجازه یک بازدید را بدهند. برنامه شما باید از این رفتارها پشتیبانی کند.

در صورت امکان، ابزار جایگزینی برای انجام همان عملکرد ارائه کنید

نتیجه برخی از قابلیت ها ممکن است برای کاربران مفید نباشد. به عنوان مثال، موقعیت جغرافیایی یک دستگاه دسکتاپ بدون سنسور GPS ممکن است مکان اشتباه را برگرداند زیرا آن شخص به VPN متصل است. سایر کاربران ممکن است نخواهند دسترسی به کلیپ بورد را فراهم کنند زیرا ترجیح می دهند کنترل خود را حفظ کنند و این رویدادها را با ترکیب کلیدها به صورت دستی فعال کنند. در شرایطی مانند این، مهم است که ابزار جایگزینی برای دستیابی به نتایج یکسان ارائه کنیم. برای مثال، در صورت درخواست مجوز موقعیت جغرافیایی، یک فیلد متنی ارائه دهید که در آن کاربران می‌توانند کد پستی یا آدرس خود را وارد کنند. با کلیپ بورد، مطمئن شوید که عناصری که باید کپی شوند را نیز می توان از طریق ترکیب کلید یا منوی زمینه انتخاب و کپی کرد. با اعلان‌ها، پیشنهاد دهید که مردم به‌جای اعلان‌های فشاری، ایمیل دریافت کنند.

یک الگوی مفید این است که از رابط کاربری جایگزین نیز به عنوان توضیحی برای اینکه چرا دسترسی می تواند مفید باشد، استفاده کنید. کاربرانی که گزینه ای برای وارد کردن یک مکان در کنار دکمه ای که API موقعیت جغرافیایی را فعال می کند می بینند، کنترل آنچه قرار است اتفاق بیفتد را می بینند، زیرا می دانند که می توانند آدرس خود را نیز تایپ کنند. به طور مشابه، اگر بین دریافت اعلان‌ها از طریق فشار یا ایمیل، یا پیوستن به جلسه بدون اجازه دسترسی به دوربین و میکروفون، انتخابی وجود داشته باشد، کاربران به طور طبیعی‌تر معاوضه‌هایی را که انجام می‌دهند، درک می‌کنند.

خود را در حالت مسدود قرار ندهید، بهبودی از آن سخت است

هنگامی که کاربر تصمیم گرفت به طور دائمی اجازه دسترسی به یک قابلیت دارای مجوز را ندهد، مرورگرها به این تصمیم احترام می گذارند. اگر ادامه درخواست دسترسی امکان پذیر بود، سایت های بد قصد به بمباران کاربران با درخواست ها ادامه می دادند. بنابراین، بازیابی از حالت مسدود شده یک قابلیت، عمداً کمی تلاش کاربر را می‌طلبد. بر این اساس، در شرایطی که احتمال دارد بسیاری از کاربران اجازه دسترسی را ندهند، از درخواست مجوز از کاربران خودداری کنید.

یک راه متداول برای انجام این کار استفاده از یک به اصطلاح pre-prompt است که در آن به کاربران خود توضیح می دهید که چه اتفاقی در شرف وقوع است و چرا برنامه شما به قابلیتی که می خواهید درخواست کنید نیاز دارد. فقط زمانی که کاربران به چنین درخواستی واکنش مثبت نشان دهند، باید درخواست مجوز مرورگر را فعال کنید. شرایطی وجود دارد که کاربران ممکن است به طور قانونی نیاز به بازیابی از آن حالت داشته باشند. برای اطلاعات بیشتر در این مورد به بخش کمک به بازیابی کاربران از حالت مسدود شده مراجعه کنید.

به محتوای شخص ثالث توجه کنید

منبع غیرمنتظره ای از درخواست های مجوز وجود دارد که باید از آن آگاه باشید. اگر اسکریپت های شخص ثالث را در سایت خود قرار دهید، ممکن است درخواست های مجوزی را که شما قصد نمایش آن ها را نداشتید، راه اندازی کنند. این می‌تواند بر تجربه کاربران از وب‌سایت شما تأثیر بگذارد، به‌ویژه اگر چنین اعلان‌هایی از بهترین روش‌هایی که قبلاً ذکر شده پیروی نمی‌کنند. برای کنترل تجارب کاربران خود، باید اسناد کتابخانه ها و اسکریپت های شخص ثالثی را که به کد خود اضافه می کنید به دقت مطالعه کنید.

چه زمانی برای درخواست اجازه

در اینجا چند نمونه از لحظاتی وجود دارد که با پیروی از بهترین روش‌هایی که قبلاً توضیح داده شد، برای درخواست اجازه به خوبی کار می‌کنند:

• پس از اینکه کاربر روی دکمه‌ای کلیک کرد که می‌گوید "استفاده از موقعیت مکانی من" در کنار فیلد فرم برای وارد کردن آدرس به صورت دستی.
• پس از اینکه کاربر در یک کانال ویدیویی یا پست‌هایی مشترک شد و روی دکمه تأیید روی یک گفتگو کلیک کرد و توضیح داد که به‌روزرسانی‌ها می‌توانند به صورت ایمیل یا اعلان به تلفن یا دسکتاپ او تحویل داده شوند.
• پس از ورود کاربر به صفحه‌ای که او را برای پیوستن به یک تماس ویدیویی آماده می‌کند و به طور مثبت پاسخ می‌دهد که می‌خواهد دیده شود و در یک درخواست از قبل شنیده شود (به این مطالعه موردی از Google Meet مراجعه کنید).

الگوهای کد برای درخواست مجوز

دریافت مجوز برای استفاده از یک API بسته به API از راه های مختلفی انجام می شود. برخی از API های (معمولا قدیمی تر) از مدلی استفاده می کنند که در آن مرورگر به طور خودکار اولین باری که شما سعی می کنید از API استفاده کنید، اجازه می خواهد. یک مثال، Geolocation API هنگام فراخوانی navigator.geolocation.getCurrentPosition() است.

try {
  navigator.geolocation.getCurrentPosition((pos) => console.log(pos));
} catch (error) {
  console.error(error);
}

سایر APIها از مدلی استفاده می کنند که در آن شما به صراحت باید ابتدا با استفاده از روش ایستا مجوز درخواست کنید. یک مثال خوب Notification.requestPermission() برای اجازه دادن به اعلان‌ها یا DeviceOrientationEvent.requestPermission() کمتر رایج است که بخشی از Device Orientation Events API است. توجه داشته باشید که برخی از مرورگرها ممکن است به طور خودکار به API های داده شده مجوز دهند. برای مثال، Chrome همیشه اجازه دسترسی به جهت دستگاه را می دهد، در حالی که Safari یک درخواست را نشان می دهد.

const result = await DeviceOrientationEvent.requestPermission();
console.log(`The user's decision when prompted to use the Device Orientation
Events API was: ${result}.`);
if (result === 'granted') {
  /* Use the API. */
}

نحوه بررسی وضعیت مجوزها

برای بررسی اینکه آیا می‌توانید از API خاصی استفاده کنید، از متد navigator.permissions.query() از Permissions API استفاده کنید.

const result = await navigator.permissions.query({ name: 'geolocation' });
console.log(`The result of querying for the Geolocation API is:
${result.state}.`);
if (result.state === 'granted') {
  // Use the API.
}

به کاربران کمک کنید تا از حالت مسدود شده بازگردند

برای کمک به کاربران در عیب‌یابی مشکلات دسترسی، تشخیص دهید که آنها دسترسی را با استفاده از Permissions API مسدود کرده‌اند و راهنمای نحوه تغییر تنظیمات خود را به آنها ارائه دهید. به عنوان مثال، هنگامی که کاربران با عناصر رابط کاربری که با یک قابلیت دارای مجوز مرتبط هستند تعامل دارند، از الگوی توضیح داده شده در بخش قبل استفاده کنید و یک گفتگوی عیب‌یابی را باز کنید. مراحل دقیق تغییر وضعیت مجوز بسته به مرورگر متفاوت است، بنابراین ممکن است بخواهید توضیحات منطبقی را بر اساس رشته عامل کاربر و برای مرورگرهای رایج در محصول خود ارائه دهید.

در کروم، کاربران باید با کلیک کردن روی نماد "تنظیم" در سمت چپ نوار آدرس، به کنترل‌های سایت بروند. در اینجا، آنها می توانند مجوز مربوطه را روشن کنند. در برخی موارد، ممکن است مجبور شوند قبل از استفاده از قابلیت، صفحه را دوباره بارگیری کنند. در این صورت، یک نوار پیام در بالای پنجره نشان داده می شود که با کلیک روی دکمه مربوطه، بارگیری مجدد را ارائه می دهد.

رابط‌های کاربری مشابهی برای کنترل مجوزها در سایر مرورگرها وجود دارد (به عنوان مثال، ببینید این کار در فایرفاکس چگونه کار می‌کند ).