API حذف کاربر - مجوز

این راهنما توضیح می‌دهد که چگونه یک برنامه درخواست‌ها را به User Deletion API مجوز می‌دهد.

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

قبل از اینکه کاربران بتوانند اطلاعات حساب خود را در وب سایت Google Analytics مشاهده کنند، ابتدا باید به حساب های Google خود وارد شوند. به طور مشابه، هنگامی که کاربران برای اولین بار به برنامه شما دسترسی پیدا می کنند، باید به برنامه شما اجازه دسترسی به داده های خود را بدهند.

هر درخواستی که برنامه شما به API آنالیتیکس ارسال می کند باید شامل یک نشانه مجوز باشد. توکن همچنین برنامه شما را در گوگل شناسایی می کند.

درباره پروتکل های مجوز

برنامه شما باید از OAuth 2.0 برای تأیید درخواست ها استفاده کند. هیچ پروتکل مجوز دیگری پشتیبانی نمی شود. اگر برنامه شما از ورود به سیستم با Google استفاده می کند، برخی از جنبه های مجوز برای شما انجام می شود.

تأیید درخواست ها با OAuth 2.0

همه درخواست‌ها به API Analytics باید توسط یک کاربر احراز هویت شده مجاز باشد.

جزئیات فرآیند مجوز یا "جریان" برای OAuth 2.0 بسته به نوع برنامه ای که می نویسید تا حدودی متفاوت است. فرآیند کلی زیر برای همه انواع برنامه ها اعمال می شود:

  1. هنگامی که برنامه خود را ایجاد می کنید، آن را با استفاده از Google API Console ثبت می کنید. سپس Google اطلاعاتی را که بعداً به آن نیاز خواهید داشت، مانند شناسه مشتری و راز مشتری ارائه می دهد.
  2. API Analytics را در Google API Console فعال کنید. (اگر API در لیست API Console نیست، از این مرحله صرفنظر کنید.)
  3. هنگامی که برنامه شما نیاز به دسترسی به داده های کاربر دارد، از Google دامنه دسترسی خاصی را می خواهد.
  4. Google یک صفحه رضایت به کاربر نمایش می دهد و از او می خواهد تا به برنامه شما اجازه دهد تا برخی از داده های خود را درخواست کند.
  5. اگر کاربر تأیید کند، گوگل به برنامه شما یک رمز دسترسی کوتاه مدت می دهد.
  6. برنامه شما با پیوست کردن رمز دسترسی به درخواست، داده های کاربر را درخواست می کند.
  7. اگر Google تشخیص دهد که درخواست شما و رمز معتبر هستند، داده‌های درخواستی را برمی‌گرداند.

برخی از جریان‌ها شامل مراحل اضافی هستند، مانند استفاده از نشانه‌های تازه‌سازی برای به دست آوردن نشانه‌های دسترسی جدید. برای اطلاعات دقیق درباره جریان‌ها برای انواع مختلف برنامه‌ها، به اسناد OAuth 2.0 Google مراجعه کنید.

در اینجا اطلاعات محدوده OAuth 2.0 برای Analytics API آمده است:

محدوده معنی
https://www.googleapis.com/auth/analytics.user.deletion با استفاده از User Delete API داده ها را حذف کنید.

برای درخواست دسترسی با استفاده از OAuth 2.0، برنامه شما به اطلاعات محدوده و همچنین اطلاعاتی که Google هنگام ثبت برنامه خود ارائه می دهد (مانند شناسه مشتری و رمز سرویس گیرنده) نیاز دارد.

نکته: کتابخانه های سرویس گیرنده Google APIs می توانند برخی از فرآیندهای مجوز را برای شما انجام دهند. آنها برای انواع زبان های برنامه نویسی در دسترس هستند. برای جزئیات بیشتر صفحه را با کتابخانه ها و نمونه ها بررسی کنید.

جریان های معمول OAuth 2.0

موارد زیر موارد استفاده متداول را برای جریان‌های خاص OAuth 2.0 فهرست می‌کند:

وب سرور

این جریان برای دسترسی خودکار، آفلاین یا برنامه ریزی شده به داده های Google Analytics کاربر خوب است.

مثال:

  • به‌روزرسانی خودکار داشبوردهای کاربر با آخرین داده‌های Google Analytics.

سمت مشتری

این جریان برای برنامه‌هایی ایده‌آل است که کاربران مستقیماً با برنامه تعامل دارند تا به داده‌های Google Analytics خود در یک مرورگر دسترسی پیدا کنند. این نیاز به قابلیت های سمت سرور را از بین می برد، اما گزارش خودکار، آفلاین یا برنامه ریزی شده را غیرعملی می کند.

مثال:

برنامه های کاربردی نصب شده

این جریان برای برنامه هایی است که به صورت بسته توزیع شده و توسط کاربر نصب می شوند. این جریان مستلزم آن است که برنامه یا کاربر برای تکمیل جریان احراز هویت به مرورگر دسترسی داشته باشد.

مثال ها:

  • ویجت دسکتاپ در رایانه شخصی یا مک.
  • یک پلاگین برای یک سیستم مدیریت محتوا - مزیت این جریان در مقایسه با وب سرور یا سمت سرویس گیرنده این است که یک پروژه کنسول API می تواند برای برنامه شما استفاده شود. این امکان گزارش تلفیقی و نصب ساده تر را برای کاربران فراهم می کند.

حساب های خدماتی

حساب های سرویس برای دسترسی خودکار، آفلاین یا برنامه ریزی شده به داده های Google Analytics برای حساب شخصی شما مفید هستند. به عنوان مثال، برای ایجاد یک داشبورد زنده از داده های Google Analytics خود و به اشتراک گذاری آن با سایر کاربران.

برای شروع استفاده از Analytics API، ابتدا باید از ابزار راه‌اندازی استفاده کنید که شما را از طریق ایجاد پروژه در کنسول API Google، فعال کردن API و ایجاد اعتبار راهنمایی می‌کند.

برای راه اندازی یک حساب سرویس جدید، موارد زیر را انجام دهید:

  1. روی ایجاد اعتبارنامه > کلید حساب سرویس کلیک کنید.
  2. انتخاب کنید که آیا کلید عمومی/خصوصی حساب سرویس به‌عنوان فایل استاندارد P12 بارگیری شود یا به‌عنوان فایل JSON که می‌تواند توسط کتابخانه سرویس گیرنده Google API بارگیری شود.

جفت کلید عمومی/خصوصی جدید شما تولید و در دستگاه شما دانلود می شود. به عنوان تنها کپی این کلید عمل می کند. شما مسئول نگهداری ایمن آن هستید.

عیب یابی

مجوز شما در این شرایط ناموفق است:

  • اگر access_token شما منقضی شده باشد یا اگر از محدوده اشتباه برای API استفاده می کنید، یک کد وضعیت 401 دریافت خواهید کرد.

  • اگر کاربر مجاز به نمای (نمایه) دسترسی نداشته باشد، کد وضعیت 403 دریافت خواهید کرد. مطمئن شوید که با کاربر صحیح مجاز هستید و آنها واقعاً نمای (نمایه) انتخابی شما را دارند.

زمین بازی OAuth 2.0

این ابزار به شما اجازه می دهد تا از طریق یک رابط وب، کل جریان مجوز را طی کنید. این ابزار همچنین تمام هدرهای درخواست HTTP مورد نیاز برای ایجاد یک پرس و جو مجاز را نمایش می دهد. اگر نمی توانید مجوز کار در برنامه خود را دریافت کنید، باید سعی کنید آن را از طریق زمین بازی OAuth 2.0 فعال کنید. سپس می توانید هدرهای HTTP را مقایسه کنید و از زمین بازی با آنچه برنامه شما به Google Analytics ارسال می کند درخواست کنید. این بررسی یک راه ساده برای اطمینان از فرمت صحیح درخواست های خود است.

کمک هزینه نامعتبر

هنگامی که سعی می کنید از یک نشانه رفرش استفاده کنید، موارد زیر یک خطای invalid_grant را به شما برمی گرداند:

برنامه‌ها می‌توانند برای دسترسی به یک حساب Google Analytics، چندین توکن به‌روزرسانی درخواست کنند.

به عنوان مثال، اگر کاربر بخواهد یک برنامه را روی چندین ماشین نصب کند و به یک حساب Google Analytics دسترسی داشته باشد، برای هر دستگاه یک توکن جداگانه لازم است. وقتی تعداد نشانه‌های تازه‌سازی از حد مجاز بیشتر شود، نشانه‌های قدیمی‌تر نامعتبر می‌شوند. اگر برنامه سعی کند از یک نشانه رفرش نامعتبر استفاده کند، یک پاسخ خطای invalid_grant برگردانده می شود.

محدودیت برای هر جفت منحصربه‌فرد مشتری OAuth 2.0 و حساب Google Analytics 25 توکن به‌روزرسانی است. اگر برنامه همچنان به درخواست نشانه‌های تازه‌سازی برای همان جفت مشتری/حساب ادامه دهد، پس از صدور بیست و ششمین نشانه، اولین نشانه به‌روزرسانی که قبلاً صادر شده بود نامعتبر می‌شود. بیست و هفتمین توکن درخواستی به‌روزرسانی، دومین توکن صادر شده قبلی و غیره را باطل می‌کند.