Хранение временных переменных для использования в приложении Loopback 4 - PullRequest
Новая
       7

Хранение временных переменных для использования в приложении Loopback 4

0 голосов
/ 15 февраля 2019

У меня есть токен аутентификации, который я хотел бы использовать в нескольких контроллерах Loopback 4.Срок действия этого токена истекает.По истечении этого срока я запускаю некоторую логику входа в систему для получения нового токена.

Моя проблема в том, что я не уверен, как или где хранить этот токен.

Так что я могу использовать это в своем приложении.Я думаю либо сохранить токен как переменную среды, например. 

process.env.AUTH_TOKEN = 'TEST';

, либо использовать контекст уровня приложения Loopback 4 https://loopback.io/doc/en/lb4/Context.html

Эти подходящие решения для хранения этогофишка?Если нет, то каким было бы альтернативное решение?

В случае использования Context, как бы я поступил так, используя лучшие практики?

1 Ответ

0 голосов
/ 20 февраля 2019

Принимая во внимание все вышеприведенные комментарии, я бы порекомендовал вам создать отдельный модуль, который будет инкапсулировать логику, связанную с вашим токеном аутентификации и тем, как вы его используете.Т.е. новый модуль будет отвечать за:

  • Выбор нового токена, когда он пуст
  • Хранение токена
  • Обновление токена после истечения срока его действия
  • Выполнение вызовов API (или что бы вы ни делали с этим токеном, извините, это не было понятно из вашего описания) - можно перенести в отдельный модуль, но это другая история

Я полагаю, ваш модуль в JavaScript может выглядеть примерно так: 

let AUTH_TOKEN = "";

function makeAPICall(some, params) {
    if (! AUTH_TOKEN) {
        acquireNewToken();
    }

    if (expired()) {
        refreshToken();
    }

    return "some_data"; // TODO: here you do you what you want with your auth token and return some data
}

function acquireNewToken() {
    authToken = "new_token"; // TODO: put the logic to acquire a new token here
}

function refreshToken() {
    authToken = "new_token"; // TODO: put the logic to refresh a token here
}

function expired() {
    return false; // TODO: put the logic to check if token expired here
}

module.exports = {
    makeAPICall: makeAPICall
};

Тогда вы можете require authModule на всех ваших контроллерах и использовать его, как показано ниже: 

let authModule = require('./modules/authModule');

authModule.makeAPICall("some", "params");

Я полагаю, вам никогда не понадобится выставлять токен аутентификации вашим контроллерам, так как вы можете реализовать всю логику, связанную с использованием токена аутентификации в authModule, и передать только некоторыеПараметры для makeAPICall функция, чтобы сказать ему, что делать и какие данные получить.Но в случае, если вам действительно нужно выставить его, вы можете немного изменить authModule (добавьте getToken функцию и добавьте ее к module.exports): 

function getToken() {
    return authToken;
}

module.exports = {
    makeAPICall: makeAPICall,
    getToken: getToken
};

Теперь давайте вернемся к вашемувопросы:

Подходят ли эти решения для хранения этого токена?Если нет, то каким было бы альтернативное решение?

Как предложено выше, решение состоит в том, чтобы сохранить токен как локальную переменную в области действия пользовательского модуля.Обратите внимание, что Node.js использует кеширование для модулей ваша переменная AUTH_TOKEN будет одинаковой на всех контроллерах (каждый новый require будет возвращать вам один и тот же объект с одинаковым токеном).

Если вы не хотите require authModule каждый раз, когда вам нужен доступ к AUTH_TOKEN, вы также можете просто объявить его как глобальную переменную: global.AUTH_TOKEN = "";.Обратите внимание, что глобальные переменные имеют свой недостаток, так как они могут вызывать неявную связь между файлами и т. Д. Вот хорошая статья о том, когда следует и когда не следует использовать глобальные переменные: https://stackabuse.com/using-global-variables-in-node-js/

ВВ случае использования Context, как бы я поступил так, используя лучшие практики?

Вы также можете использовать Loopback 4 Context, и это будет почти эквивалентно решению с пользовательским authModuleЯ предложил выше.Единственное отличие от клиентского модуля - вы можете поместить туда немного больше пользовательской логики и избежать копирования некоторых ваших кодов в контроллеры.С Loopback 4 Context вы можете использовать контекст уровня сервера и хранить там AUTH_TOKEN, но вам все равно понадобится место, где вы получите новый токен и обновите его, когда он истечет.Опять же, вы можете реализовать эту логику в пользовательском authModule.Т.е. вы можете сохранить этот пользовательский модуль и одновременно сохранить AUTH_TOKEN в Loopback Context.Это будет абсолютно нормально, но с моей точки зрения код станет немного сложнее.

...