IH
Хай, який бест практіс по "що зберігати у токенах" ? Наскільки я розумію, тільки id, бо якщо я засетаю фулл юзей інфо, то це можна просто роздекодити
Size: a a a
2020 September 12
TS
Ilya Human
Хай, який бест практіс по "що зберігати у токенах" ? Наскільки я розумію, тільки id, бо якщо я засетаю фулл юзей інфо, то це можна просто роздекодити
A
Переслано от Alexander
Кто знает хорошую литературу по использованию билд программ с помощью
Сижу курю мануалы, но информация разбросана и не понятно как использовать в разных ситуациях, в общем обычного
make / Makefile / ldconfig в Linux?Сижу курю мануалы, но информация разбросана и не понятно как использовать в разных ситуациях, в общем обычного
man не хватает.АП
Почитайте и не переживайте за раст ))) @fatSleeper @murzilka17
https://blog.rust-lang.org/2020/08/18/laying-the-foundation-for-rusts-future.html
https://blog.rust-lang.org/2020/08/18/laying-the-foundation-for-rusts-future.html
Не буду переживать даже если он утонет, но статья особо ни о чём
happy to announce plans to create a Rust foundation
Счастье то, 🥞, какое
happy to announce plans to create a Rust foundation
Счастье то, 🥞, какое
2020 September 13
ЕБ
Привет, друзья. У меня вопрос, как в gulpfile.js передать секретный api key да так, чтобы он не засветился github. Я думаю вариант использовать .env, его соответственно в gitignore, а при деплои уже ключи на сервере настроить, как то так. Что скажите?
АК
Привет, друзья. У меня вопрос, как в gulpfile.js передать секретный api key да так, чтобы он не засветился github. Я думаю вариант использовать .env, его соответственно в gitignore, а при деплои уже ключи на сервере настроить, как то так. Что скажите?
Как-то так и надо)
АБ
Привет, друзья. У меня вопрос, как в gulpfile.js передать секретный api key да так, чтобы он не засветился github. Я думаю вариант использовать .env, его соответственно в gitignore, а при деплои уже ключи на сервере настроить, как то так. Что скажите?
Мысль неплохая, но светить ключами на все приложение, особенно если оно ходит в тырнет, может быть не самой здравой идеей. Подумайте над форматом с простым конфигом.
ЕБ
Мысль неплохая, но светить ключами на все приложение, особенно если оно ходит в тырнет, может быть не самой здравой идеей. Подумайте над форматом с простым конфигом.
спасибо
АБ
Господа архитекторы, есть такой вопрос.
Есть абстрактный сервис, который является некой прокладкой к другим сервисам. При этом, логика такова, что, без доступа к этим сторонним ресурсам, наше сервис ничего не может, ему нужно сначала получить данные со стороннего сервиса, а уже затем на их основе выполнять определенные задачи.
С применением oAuth протокола, процесс создания пользовательского аккаунта такого сервиса условно делится на 3 этапа(условно):
1) Хэндлер 1 получает запрос на создание аккаунта пользователя и отдает ссылку с client_id и redirect_uri.
2) Предоставление прав доступа к стороннему сервису пользователем
3) Хэндлер 2 нашего сервиса получает код авторизации и обменивает его на токен для доступа к стороннему сервису и заполнение аккаунта данными.
Но помимо сервисов, которые поддерживают только oAuth, есть и такие сервисы, которые дают api ключ, который нужно ручками вставить и пользоваться сразу.
Получается, что в случае с oAuth логика создания аккаунта размазывается на 2 этапа, в 2 разных местах программы. В случае же с api key все можно сделать одним запросом.
При этом, очень хотелось бы абстрагировать процесс создания разных типов аккаунтов и и сделать все процессы как можно более унифицированными, скрыть их реализацию за каким-то интерфейсом, условно в одном методе connect(), стоит ли и можно или это сделать и если да, то как бы вы сделали?
Есть абстрактный сервис, который является некой прокладкой к другим сервисам. При этом, логика такова, что, без доступа к этим сторонним ресурсам, наше сервис ничего не может, ему нужно сначала получить данные со стороннего сервиса, а уже затем на их основе выполнять определенные задачи.
С применением oAuth протокола, процесс создания пользовательского аккаунта такого сервиса условно делится на 3 этапа(условно):
1) Хэндлер 1 получает запрос на создание аккаунта пользователя и отдает ссылку с client_id и redirect_uri.
2) Предоставление прав доступа к стороннему сервису пользователем
3) Хэндлер 2 нашего сервиса получает код авторизации и обменивает его на токен для доступа к стороннему сервису и заполнение аккаунта данными.
Но помимо сервисов, которые поддерживают только oAuth, есть и такие сервисы, которые дают api ключ, который нужно ручками вставить и пользоваться сразу.
Получается, что в случае с oAuth логика создания аккаунта размазывается на 2 этапа, в 2 разных местах программы. В случае же с api key все можно сделать одним запросом.
При этом, очень хотелось бы абстрагировать процесс создания разных типов аккаунтов и и сделать все процессы как можно более унифицированными, скрыть их реализацию за каким-то интерфейсом, условно в одном методе connect(), стоит ли и можно или это сделать и если да, то как бы вы сделали?
2020 September 14
A
getAffectedItemsCount() для чего нужен не понял
o
Господа архитекторы, есть такой вопрос.
Есть абстрактный сервис, который является некой прокладкой к другим сервисам. При этом, логика такова, что, без доступа к этим сторонним ресурсам, наше сервис ничего не может, ему нужно сначала получить данные со стороннего сервиса, а уже затем на их основе выполнять определенные задачи.
С применением oAuth протокола, процесс создания пользовательского аккаунта такого сервиса условно делится на 3 этапа(условно):
1) Хэндлер 1 получает запрос на создание аккаунта пользователя и отдает ссылку с client_id и redirect_uri.
2) Предоставление прав доступа к стороннему сервису пользователем
3) Хэндлер 2 нашего сервиса получает код авторизации и обменивает его на токен для доступа к стороннему сервису и заполнение аккаунта данными.
Но помимо сервисов, которые поддерживают только oAuth, есть и такие сервисы, которые дают api ключ, который нужно ручками вставить и пользоваться сразу.
Получается, что в случае с oAuth логика создания аккаунта размазывается на 2 этапа, в 2 разных местах программы. В случае же с api key все можно сделать одним запросом.
При этом, очень хотелось бы абстрагировать процесс создания разных типов аккаунтов и и сделать все процессы как можно более унифицированными, скрыть их реализацию за каким-то интерфейсом, условно в одном методе connect(), стоит ли и можно или это сделать и если да, то как бы вы сделали?
Есть абстрактный сервис, который является некой прокладкой к другим сервисам. При этом, логика такова, что, без доступа к этим сторонним ресурсам, наше сервис ничего не может, ему нужно сначала получить данные со стороннего сервиса, а уже затем на их основе выполнять определенные задачи.
С применением oAuth протокола, процесс создания пользовательского аккаунта такого сервиса условно делится на 3 этапа(условно):
1) Хэндлер 1 получает запрос на создание аккаунта пользователя и отдает ссылку с client_id и redirect_uri.
2) Предоставление прав доступа к стороннему сервису пользователем
3) Хэндлер 2 нашего сервиса получает код авторизации и обменивает его на токен для доступа к стороннему сервису и заполнение аккаунта данными.
Но помимо сервисов, которые поддерживают только oAuth, есть и такие сервисы, которые дают api ключ, который нужно ручками вставить и пользоваться сразу.
Получается, что в случае с oAuth логика создания аккаунта размазывается на 2 этапа, в 2 разных местах программы. В случае же с api key все можно сделать одним запросом.
При этом, очень хотелось бы абстрагировать процесс создания разных типов аккаунтов и и сделать все процессы как можно более унифицированными, скрыть их реализацию за каким-то интерфейсом, условно в одном методе connect(), стоит ли и можно или это сделать и если да, то как бы вы сделали?
Почитайте про паттерн Strategy
NK
🚀 JavaScript fwdays’20 Autumn: 2 субботы + 4 будних вечера
22 сентября доклад "Node.js Middleware – Never again!" Тимур Шемсединов
Код -15% для нашего сообщества: metarhia
Сегодня 14 сентября вечером смотрите диалог об архитектуре Мелихова и Турского
Регистрация: https://bit.ly/3igCFa5
22 сентября доклад "Node.js Middleware – Never again!" Тимур Шемсединов
Код -15% для нашего сообщества: metarhia
Сегодня 14 сентября вечером смотрите диалог об архитектуре Мелихова и Турского
Регистрация: https://bit.ly/3igCFa5
Y
Node.js
Так что же не так с express?
AA
Так что же не так с express?
Он медленный. И конфижится... кхм... неочевидно
Т
а как же NestJS?
D
а как же NestJS?
Там же экспресс вроде под капотом
TS
Так что же не так с express?
об этом я в докладе и расскажу и как делать хорошо
Т
об этом я в докладе и расскажу и как делать хорошо
Дорого, мы сток не зарабатываем(
Y
об этом я в докладе и расскажу и как делать хорошо
Супер, спасибо!