#rest #api
#rest #API
Вопрос:
Операция GET предназначена для извлечения ресурса. И это прекрасно, но бывают ситуации, когда вы хотите, например
/:Идентификатор учетной записи / транзакции
Теперь, предполагая, что аутентификация и авторизация уже есть, как я могу гарантировать, что кто-то не будет угадывать: AccountId другого пользователя и получать транзакции, которые не принадлежат их учетной записи?
Есть ли какое-либо решение, кроме внутренней проверки AccountId?
Я не могу перейти с GET на POST также не могу использовать заголовки, поскольку API уже определен и принят клиентом.
Ответ №1:
Вы можете создать токен аутентификации для проверки запроса каждый раз, при создании токена вы должны использовать username or userid , который представляет пользователя в нем.
Во-вторых, при проверке токена вы можете проверить, что он accountID принадлежит пользователю, имя / идентификатор которого совпадают, иначе в ответ возвращается ошибка.
Таким образом, возникают накладные расходы на сопоставление accountId идентификатора пользователя / имени, но это решит вашу проблему.
Приветствия!!
Комментарии:
1. Привет, спасибо за быстрый ответ. Создавая токен аутентификации с использованием имени пользователя, вы имеете в виду, например, подход HMAC? Если это так, я мало что могу сделать, поскольку уже существует аутентификация на основе токенов, но без какого-либо отношения к идентификатору пользователя / имени. Кажется, единственный способ — выполнить проверку идентификатора учетной записи на внутренних сервисах.
2. Нет, я не говорю о подходе HMAC, вместо этого, когда мы используем аутентификацию на основе токенов, мы использовали для создания токена одно из полей, то есть userId / username, поэтому мы будем использовать то же самое, а затем проверять AccountId по отношению к userId. Но, как я уже упоминал, это будет накладно каждый раз
Ответ №2:
Я думаю, вы можете попробовать использовать пользовательскую хэш-логику для идентификатора учетной записи. Та же самая хэш-логика может использоваться на стороне сервера для получения фактического значения. Таким образом, вы можете защитить прямой способ угадывания идентификатора учетной записи пользователем.
Примечание: Я предлагаю описанный выше подход вместе с проверкой идентификатора учетной записи сервера.
например: если идентификатор учетной записи: 1000, то хэшируйте его 9888 на стороне сервера, сопоставьте его с фактическими значениями. (Вы можете увеличить сложность хэширования)