ДК
Храните этот апи ключ в открытом виде у себя?
Size: a a a
2020 August 20
AE
В ключе имя пользователя зашито что ли или как вы этого пользователя находите?
запросом в базе скорее всего
AE
по токену
С
Нет, не зашито. Хранить можно по разному. Но обычно хватает таблицы в БД.
ДК
по токену
Так это сенситив дата
С
Можно в волт
ДК
С
Можно в волт
Ты не должен иметь доступа к паролям пользователя
ДК
Короче, смотрите, чё я накидал в соседнем чате
ДК
Ладно, оцените тогда мою предполагаемую реализацию.
Предусловия:
Есть сервер авторизации oauth2. Есть ресурс серверы, к которым собственно предполагается предоставлять доступ.
Предполагаемая реализация:
Пользователь делает запрос из авторизованной зоны, нажав на кнопку "сгенерировать приватный токен"
Запрос идёт в сервер авторизации, где мы генерируем для юзера вечный jwt с нужными скоупами (для простоты), создаём приватный аксес токен, который мы хэшируем bcrypt-ом, так как это сенситив дата, привязываем эту связку к пользователю. Сходу вижу минус в вечном токене и в том, что мы храним его в открытом виде. Шифровать его симметричным ключом что ли? Например, тем же private access token-ом, который будет храниться захэшированным.
Использование юзером:
Пользователь передает в заголовке username + private access token.
На gateway мы ищем пользователя в базе и проверяем, матчится ли pat с хэшом в базе. Если да, то расшифровываем pat-ом вечный токен и передаём его дальше по цепочке к ресурс серверам.
Что скажете? Где я ебанулся?
Предусловия:
Есть сервер авторизации oauth2. Есть ресурс серверы, к которым собственно предполагается предоставлять доступ.
Предполагаемая реализация:
Пользователь делает запрос из авторизованной зоны, нажав на кнопку "сгенерировать приватный токен"
Запрос идёт в сервер авторизации, где мы генерируем для юзера вечный jwt с нужными скоупами (для простоты), создаём приватный аксес токен, который мы хэшируем bcrypt-ом, так как это сенситив дата, привязываем эту связку к пользователю. Сходу вижу минус в вечном токене и в том, что мы храним его в открытом виде. Шифровать его симметричным ключом что ли? Например, тем же private access token-ом, который будет храниться захэшированным.
Использование юзером:
Пользователь передает в заголовке username + private access token.
На gateway мы ищем пользователя в базе и проверяем, матчится ли pat с хэшом в базе. Если да, то расшифровываем pat-ом вечный токен и передаём его дальше по цепочке к ресурс серверам.
Что скажете? Где я ебанулся?
AE
Ладно, оцените тогда мою предполагаемую реализацию.
Предусловия:
Есть сервер авторизации oauth2. Есть ресурс серверы, к которым собственно предполагается предоставлять доступ.
Предполагаемая реализация:
Пользователь делает запрос из авторизованной зоны, нажав на кнопку "сгенерировать приватный токен"
Запрос идёт в сервер авторизации, где мы генерируем для юзера вечный jwt с нужными скоупами (для простоты), создаём приватный аксес токен, который мы хэшируем bcrypt-ом, так как это сенситив дата, привязываем эту связку к пользователю. Сходу вижу минус в вечном токене и в том, что мы храним его в открытом виде. Шифровать его симметричным ключом что ли? Например, тем же private access token-ом, который будет храниться захэшированным.
Использование юзером:
Пользователь передает в заголовке username + private access token.
На gateway мы ищем пользователя в базе и проверяем, матчится ли pat с хэшом в базе. Если да, то расшифровываем pat-ом вечный токен и передаём его дальше по цепочке к ресурс серверам.
Что скажете? Где я ебанулся?
Предусловия:
Есть сервер авторизации oauth2. Есть ресурс серверы, к которым собственно предполагается предоставлять доступ.
Предполагаемая реализация:
Пользователь делает запрос из авторизованной зоны, нажав на кнопку "сгенерировать приватный токен"
Запрос идёт в сервер авторизации, где мы генерируем для юзера вечный jwt с нужными скоупами (для простоты), создаём приватный аксес токен, который мы хэшируем bcrypt-ом, так как это сенситив дата, привязываем эту связку к пользователю. Сходу вижу минус в вечном токене и в том, что мы храним его в открытом виде. Шифровать его симметричным ключом что ли? Например, тем же private access token-ом, который будет храниться захэшированным.
Использование юзером:
Пользователь передает в заголовке username + private access token.
На gateway мы ищем пользователя в базе и проверяем, матчится ли pat с хэшом в базе. Если да, то расшифровываем pat-ом вечный токен и передаём его дальше по цепочке к ресурс серверам.
Что скажете? Где я ебанулся?
а доступ должен быть на весь апи?
ДК
а доступ должен быть на весь апи?
Ну при создании jwt либо мы определяем доступные юзеру скоупы, либо мы как-то программно это будем делать. Ну, это уже на самом деле детали.
Не на весь апи.
Не на весь апи.
ДК
Там детали типа если услуга платная, то мы будем проверять, оплачена ли она и в зависимости от того, до какого дня оплачена дату экспирации выставлять, например
ДК
Ну или ещё как-то, хз
С
Зачем username в запросе?
ДК
С
Зачем username в запросе?
Чтобы найти пользователя?
А
Всем привет, нужен совет по архитектуре
я делаю программу чтобы в одно время я мог торговать одновременно с разных аккаунтов в разных криптобиржах.
И тут вопрос, для каждой криптобиржи есть свои запросы, если добавлять в каждый метод реализации if(exchange=="HitBtc") request=... и так далее, то выйдет много кода и много условных выражений, и если есть много аккаунтов это существенно замедлит работу.
И вот как это можно сделать лучше, или просто разделить на несколько програм под каждую биржу одна программа?
я делаю программу чтобы в одно время я мог торговать одновременно с разных аккаунтов в разных криптобиржах.
И тут вопрос, для каждой криптобиржи есть свои запросы, если добавлять в каждый метод реализации if(exchange=="HitBtc") request=... и так далее, то выйдет много кода и много условных выражений, и если есть много аккаунтов это существенно замедлит работу.
И вот как это можно сделать лучше, или просто разделить на несколько програм под каждую биржу одна программа?
С
Может тогда лучше хотя бы SID
A
Ладно, оцените тогда мою предполагаемую реализацию.
Предусловия:
Есть сервер авторизации oauth2. Есть ресурс серверы, к которым собственно предполагается предоставлять доступ.
Предполагаемая реализация:
Пользователь делает запрос из авторизованной зоны, нажав на кнопку "сгенерировать приватный токен"
Запрос идёт в сервер авторизации, где мы генерируем для юзера вечный jwt с нужными скоупами (для простоты), создаём приватный аксес токен, который мы хэшируем bcrypt-ом, так как это сенситив дата, привязываем эту связку к пользователю. Сходу вижу минус в вечном токене и в том, что мы храним его в открытом виде. Шифровать его симметричным ключом что ли? Например, тем же private access token-ом, который будет храниться захэшированным.
Использование юзером:
Пользователь передает в заголовке username + private access token.
На gateway мы ищем пользователя в базе и проверяем, матчится ли pat с хэшом в базе. Если да, то расшифровываем pat-ом вечный токен и передаём его дальше по цепочке к ресурс серверам.
Что скажете? Где я ебанулся?
Предусловия:
Есть сервер авторизации oauth2. Есть ресурс серверы, к которым собственно предполагается предоставлять доступ.
Предполагаемая реализация:
Пользователь делает запрос из авторизованной зоны, нажав на кнопку "сгенерировать приватный токен"
Запрос идёт в сервер авторизации, где мы генерируем для юзера вечный jwt с нужными скоупами (для простоты), создаём приватный аксес токен, который мы хэшируем bcrypt-ом, так как это сенситив дата, привязываем эту связку к пользователю. Сходу вижу минус в вечном токене и в том, что мы храним его в открытом виде. Шифровать его симметричным ключом что ли? Например, тем же private access token-ом, который будет храниться захэшированным.
Использование юзером:
Пользователь передает в заголовке username + private access token.
На gateway мы ищем пользователя в базе и проверяем, матчится ли pat с хэшом в базе. Если да, то расшифровываем pat-ом вечный токен и передаём его дальше по цепочке к ресурс серверам.
Что скажете? Где я ебанулся?
вечный токен в открытом виде - это очень плохо
расшифровка токена на каждый запрос - это нехилая нагрузка на процессор
можно использовать refresh_token и хранить его у пользователя зашифрованным, а acces_token ротировать
расшифровка токена на каждый запрос - это нехилая нагрузка на процессор
можно использовать refresh_token и хранить его у пользователя зашифрованным, а acces_token ротировать
ДК
Alchemist
вечный токен в открытом виде - это очень плохо
расшифровка токена на каждый запрос - это нехилая нагрузка на процессор
можно использовать refresh_token и хранить его у пользователя зашифрованным, а acces_token ротировать
расшифровка токена на каждый запрос - это нехилая нагрузка на процессор
можно использовать refresh_token и хранить его у пользователя зашифрованным, а acces_token ротировать
Ну вот я предложил в итоге шифровать pat-ом.
Аксес токен действительно придётся ротировать, так как в зависимости от текущего состояния пользователя, набор доступных ресурсов для него будет меняться
Аксес токен действительно придётся ротировать, так как в зависимости от текущего состояния пользователя, набор доступных ресурсов для него будет меняться
ДК
Да, мне нравится идея шифровать только рефреш токен. Шифровать патом норм идея в итоге или так себе?