Підхід, який працює у 2019 році
Нещодавно я намагався досягти чогось подібного (до випадку використання, описаного в цій темі), але хотів переконатися, що я поважаю поточну політику Facebook, тому я провів невелике дослідження і тут я ділюся тим, що знайшов.
Мій випадок використання
Отже, як я вже говорив, мій випадок використання дуже схожий на описаний тут; це є:
- Я займаюся деякою роботою для шкільного округу.
- Вони використовують програмний інструмент для управління майже всім, що стосується шкільного транспорту.
- Цей інструмент дозволяє їм надсилати сповіщення електронною поштою (абонентам), коли вони публікують сповіщення про затримку автобусів та попередження про закриття школи.
- Багато людей у спільноті стежать за організацією на своїй сторінці у Facebook, і це єдине місце, де вони шукають ці сповіщення.
- Тож працівнику організації доводиться вручну публікувати кожне повідомлення на сторінці у Facebook (крім створення в транспортному ПЗ). Більше того, ці сповіщення з часом закінчуються (або просто видаляються до того, як вони закінчуються), тому працівник повинен повернутися пізніше, щоб також видалити їх вручну.
- Це талія часу, тому те, що ми намагаємось тут зробити, - це розробити як просту систему, яка періодично опитує базу даних програмного засобу для отримання нових (і минулих) сповіщень та оновлює їх (тобто додає та видаляє) на сторінці Facebook.
На мій погляд, це законний випадок використання, але я не був впевнений, як його реалізувати таким чином, що відповідає політиці Facebook.
Прийнята відповідь
Я дотримувався кроків прийнятої відповіді, і вона спрацювала, за винятком того, що речі, здається, змінилися: тепер, навіть якщо створений маркер сторінки не закінчується, access to dataвін закінчується приблизно через 60 днів. Це ви також побачите, якщо дотримуватися процедури та перевірити маркер сторінки в інструменті налагодження FB Token .
Крім того, невдалим є і той факт, що створені жетони сторінки прив’язані до облікового запису користувача, оскільки якщо користувач оновить свій пароль, то маркер сторінки також буде недійсним.
Як це зробити у 2019 році
Після кількох годин досліджень я натрапив на наступну статтю з документацією у Facebook: Вхід для бізнесу для прямого бізнесу .
Виявляється, тепер можна, виконавши кроки, описані у вищевказаній статті, створити маркер сторінки, який не пов’язаний з будь-яким конкретним обліковим записом користувача Facebook і який не закінчиться (якщо тільки не вилучено додаток FB або маркер додатка, що лежить в основі) видаляється, ви знаєте ...)
Ось ось етапи та найважливіші частини:
- Вам потрібен обліковий запис Business Manager .
- Потрібна перевірка, і цифровий договір потрібно буде підписати.
- Вам потрібно додати цільову сторінку Facebook до цього облікового запису.
- Вам потрібно створити додаток Facebook і перенести цю програму в той самий обліковий запис Business Manager.
- Додаток повинен буде пройти процес перегляду у Facebook, оскільки знадобляться наступні дозволи:
manage_pagesі publish_pages.
- Важлива примітка Щоб публікації, створені за допомогою маркера сторінки генерування, були видимі для користувачів, окрім адміністраторів додатків, цей додаток потрібно буде опублікувати та затвердити.
- Ви все ще можете експериментувати з цією концепцією, не надсилаючи її на огляд, але публікації не будуть публічно видимими.
- У обліковому записі Business Manager (лише після додавання вашої програми та сторінки до облікового запису) потрібно створити те, що називається користувачем системи , і надати цій адміністраторі роль (або дозволи) для цільової сторінки Facebook.
- Користувач системи належить обліковому запису Business Manager і не прив’язаний до конкретного користувача. На сьогоднішній день я розумію, що одним із головних випадків використання користувачем системи є програмний доступ до Graph API у Facebook (саме те, що нам потрібно).
- Тоді для цього системного користувача потрібно створити маркер доступу (який не закінчується). Вам буде запропоновано вибрати для якого додатка. Потім ви виберете цільовий додаток.
- Потім вам потрібно буде скористатись згенерованим маркером програми, щоб створити маркер сторінки, який також не закінчується. У цій статті процедура описана як:
GET /<PAGE_ID>?fields=access_token&access_token=<SYSTEM_USER_ACCESS_TOKEN>
Цей маркер ніколи не закінчиться, і він не буде прив’язаний до конкретного користувача Facebook, тому це саме те, що нам потрібно!
Остання частина полягає в тому, щоб переконатися, що ваш додаток Facebook затверджено Facebook. Насправді це найважливіша частина, адже вся процедура марна, якщо люди не бачать наших постів.
Мені хотілося точно знати, що я можу покластися на описану вище процедуру, щоб створити щось для свого клієнта, не відкинувши це в кінцевому підсумку, тому, заздалегідь (тобто перед тим, як почати працювати над проектом мого клієнта), я пройшов весь процес створення сторінки, програми, облікового запису Business Manager тощо. Я підтвердив свою справу. Я надіслав свою заявку на розгляд. У своєму запиті я був дуже конкретним щодо мого випадку використання і підкреслив, що додаток призначений для "самостійного використання" (тобто організація розробляє додаток для себе, а не для інших користувачів Facebook). Мене схвалили не менше ніж за 24 години.
Кілька інших приміток щодо процесу перегляду додатків:
- Мені довелося вибрати платформу для програми, тому я вибрав веб-сайт .
- Я повинен був вказати, чому додатку потрібні два дозволи та як він буде ним користуватися.
- Мені довелося вказати, чому рецензент не зможе увійти в свій додаток і спробувати його (тобто тому, що додаток буде використовуватися робочим процесом).
- Для обов'язкових екрані я просто представив ручні операції в терміналі за допомогою
curl утиліти (для генерації маркера сторінки та розміщення публікацій на сторінці у Facebook). Я також показав, як я використовував Business Manager для прив’язки користувача системи до сторінки та генерування маркера тощо.
- Знову ж таки, я був дуже конкретним щодо мого використання, і думаю, що це допомогло.
Сподіваюся, ця інформація буде корисна людям із подібними випадками використання.