Лучший способ передать функцию авторизации на другую страницу с nodeJS - PullRequest
Новая
       33

Лучший способ передать функцию авторизации на другую страницу с nodeJS

0 голосов
/ 06 февраля 2020

Я работаю с Google Calendar API для nodeJS и смог пройти аутентификацию с помощью oauth2. Пример работает правильно и отображает события из моего календаря на консоль. Файлы токенов и учетных данных JSON хранятся в том же каталоге, что и скрипт, который я использую.

Моя цель - отобразить те события, которые находятся в одном опубликованном календаре c, в отдельном событии. стр. Страница событий - это открытая c, stati c страница, написанная с HTML и включающая в себя JS. Я хотел бы использовать NodeJS, потому что сейчас я создаю проект с ним.

Я знаю, что есть несколько способов сделать это. Как и ожидалось, события можно добавлять и удалять в любое время, и я бы хотел, чтобы на странице событий отображался список событий в тот момент, когда пользователь publi c посещает страницу stati c. Код, который я использую, можно найти в документации Google API здесь

1 Ответ

0 голосов
/ 06 февраля 2020

Вы упомянули две совершенно разные вещи в своем редакторе.

  • Первая ссылка относится к Node.js API, который позволяет загружать события из Календаря на СЕРВЕР и взаимодействовать с Календарем для манипулировать им.
  • Второй позволяет встроить календарь на веб-страницу. При использовании второго вам не нужен серверный код. Ваш CLIENT_ID и ваш API_KEY должны быть публично предоставлены на веб-странице, но это нормально, они предназначены для такого использования.

ОРИГИНАЛЬНЫЙ ОТВЕТ

Здесь речь идет об архитектуре кода, поэтому в качестве решения может быть предложено не так много простых фрагментов кода. Сначала вам нужно выяснить, что ваша система собирается делать с концептуальной точки зрения:

  1. Является ли ваш «веб-сайт» (как мы говорим о страницах, но это может быть и API) ) система вещания. Следовательно, он аутентифицируется в 1 (или любом количестве) Календарей Google и предоставляет его содержимое любому пользователю, который получает к нему доступ
  2. ИЛИ ваша система будет предоставлять информацию из разных Календарей разным пользователям

Концептуально они очень разные, так как в первом случае ваш сервер должен получить доступ к n Календари и хранить эти ключи, доступные любому пользователю, поэтому вы можете хранить их в переменной, доступной для любой конечной точки, которой нужны эти данные. Во втором случае вам необходимо получить доступ к k календарям для каждого пользователя и обеспечить согласованное связывание между ними.

В любом случае не должно быть серьезных проблем с перемещением auth token на одном и том же сервере. до тех пор, пока вы не отправите его случайно в любом ответе.

Кроме того, я не совсем уверен, какие функции Календаря вы используете, но я думаю, что API-интерфейсы Календаря предназначены для срабатывания только несколько раз и так вы не можете просто пересылать запрос API календаря каждый раз, когда пользователь переходит на страницу, где эти данные будут отображаться, а наоборот; Выполните аутентификацию в Calendar API, загрузите данные календаря и сохраните их локально, используйте эти данные для создания своих страниц, а затем через некоторое время обновите sh локальную копию календаря (это будет работать, если ваша система соответствует пункту 1 / но может быть улучшен для работы даже для систем типа 2).

...