[JAVA] OpenFegin реализует аутентификацию подписи параметра интерфейса (1)

Java задняя часть
[JAVA] OpenFegin реализует аутентификацию подписи параметра интерфейса (1)

Мало знаний, большой вызов! Эта статья участвует в "Необходимые знания для программистов«Творческая деятельность

Эта статья участвовала в "Проект «Звезда раскопок»”, чтобы выиграть творческий подарочный пакет и бросить вызов творческим поощрительным деньгам.

В своей повседневной разработке мы часто подключаемся к каким-то сторонним sdkapi, и при подключении к этим sdk мы неизбежно сталкиваемся с проблемой аутентификации подписи параметров, для объяснения которой я воспользуюсь двумя статьями.Что такое аутентификация подписи параметра интерфейса,так же какOpenFeignКак реализовать аутентификацию подписи параметра интерфейса. Давайте начнем

Почему интерфейсы используют сигнатуры параметров?

Некоторые студенты, возможно, не подвергались проверке подписи параметров, ниже мы поговорим о сцене и зачем она нужна 😍.

Когда мы используем сторонний SDK, нам обычно не нужно входить в систему для получения информации для аутентификации. Зачем? Если используется вход в систему, процесс становится громоздким, и возникает проблема с сохранением аутентификационной информации. Таким образом, мы можем обнаружить, что общее трехстороннееоткрыть сдкапиинтерфейс, предоставит намappkey(некоторые называлиappid, все равно одно и то же) иappsecretвместо входа в систему. У некоторых друзей возникнут сомнения, какое это имеет отношение к проверке подписи параметров? 🤪 Не паникуйте, мы будем делать это медленно.

image.png

Во-первых, давайте подумаем об этом, есть только одинappkeyа такжеappsecretКак мы реализуем аутентификацию интерфейса? Учащиеся могут закрыть глаза и немного подумать. напрямуюappkeyа такжеappsecretОн напрямую передается как открытый текст параметра? 🤓, хи-хи, наверное, никто из одноклассников так не думает. . .

image.png

Давайте проясним,appkeyпокажи, кто ты,appsecretпоказыватьты настоящий ты, два значенияappkeyа такжеappsecretОн должен быть включен в информацию о запросе. чтобы другие тебя нашли,appkeyОн должен быть передан непосредственно другой стороне (ps: он может быть в виде открытого текста или зашифрован, пока согласование завершено, ничего не будет иметь значения),appsecretнужно использовать некоторые"шифрование"Метод скрыт в параметрах.Во время аутентификации идентификационная информация сравнивается на предмет совпадения.okпройти через,соответствоватьошибка, тогда пока. Чего нам сейчас не хватает, так это чего-то"шифрование"вверх. Не будем распродавать, просто скажем об этом в кавычках"шифрование"Как это обычно делается.

20180129234948_UPGeXa.gif

  1. Общая трехсторонняя открытая sdkapi потребует не менее трех параметров,appkey,sign,timestamp, эти три параметра могут иметь свои имена, прежде всегоappkey, некоторые трехсторонние SDK называютсяappid, это не о чем говорить, это используется, чтобы показать личность. за которым следует третий параметрtimestamp(Это всего лишь прокси, ссылаясь наappkey,signдругие необходимые параметры), это более наворочено, может название у каждой трехпартийной сдк разное, оно чаще встречается, может называтьсяtimestamp,nonce,salt,randПодождите, это также может быть комбинация нескольких, ее роль в основном состоит в том, чтобы дать второй параметрsignГенерация параметра включения, который действует на нас и второй параметрsignДавайте поговорим об этом вместе, а теперь поговорим об основных параметрах сигнатуры параметров.sign.

  2. signОбычно генерируется алгоритмом хеширования, исходная строка обычно генерируетсяappkey + appsecret + Параметры запроса или тело запроса + timestampсплайсинг (данное правило сплайсинга эквивалентно упомянутому в предыдущем абзаце"шифрование"метод), после нашего общего алгоритма хешированияMD5илиSHA-1После обработки получаем наш окончательныйsign. Умные друзья могут уже понять, зачем мы это делаем.Когда мы получаем параметры в бэкенде, мы передаемappkeyПолучите соответствующий пользовательскийappsecret, если не найденоappsecret, он должен не пройти аутентификацию напрямую, а затем следовать соглашению"шифрование"Параметры объединяются таким же образом, а затем тот же алгоритм хеширования используется для генерацииsign, параметры с final и параметрыsignСравнение,если последовательно, сертифицирован. Еще один момент, который следует отметить здесьПараметры запроса или тело запросаЭто должно быть для обеспечения согласованности объявления документа интерфейса, чтобы гарантировать, что серверная часть получаетПараметры запроса или тело запросапоследовательно, что приводит кsignНепредвиденных ошибок не будет.

  3. У некоторых студентов могут возникнуть такие вопросы? Третий параметр в предыдущем абзацеtimestampЧто толку, если убрать этот параметр, бэкенд будет работать так же хорошо. Это хорошая идея, остроумный мальчик, но с этим будут проблемы, если этоадрес запросаПойманные другими, другие могут продолжать получать доступ к этомуадрес запросаПолучите ресурс, результат внутренней проверки всегда будет пройден, поэтому третий параметрtimestampсущественный.

  4. У разных поставщиков sdkapi реализация и уровень безопасности каждого из них также несовместимы.Если уровень безопасности низкий, третий параметр может бытьtimestampПросто нужно уникальное случайное значениеnonceВот и все, бэкенду остается только судить об этомnonceНезависимо от того, использовался ли он, если он использовался, он будет признан неудачным, чтобы гарантировать, что каждый запрос уникален. В то время как некоторые из них имеют высокий уровень безопасности, третий параметрtimestampОн может состоять из двух параметров или более. Перейдем к более общему, третьему параметруtimestampпоtimestampметка времени, аnonceОн состоит из случайных значений. Когда бэкэнд проверяет, он не только оцениваетnonceБыл ли он использован, и это также проверимtimestampНа сколько отличается от серверного времени, если разница большенекоторое значение, он также будет признан не прошедшим. Например, для бэкенда установлено значение5 секунд, то временная метка каждого запроса по сравнению со временем сервера не может превышать5 секунд, интервал превышает5 секундЗапрос будет идентифицирован как повторная атака или неправильный запрос, что в значительной степени обеспечивает безопасность интерфейса. Если вы понимаете этот принцип, третий параметрtimestampестьN видоввозможные комбинации.

С небольшим внутренним мышлением, за мою работу в течение нескольких летНовичок в бэкендеНапример, этот третий параметрtimestampизN видовВ комбинации однозначно лучше timestamped.Если вы хотите обеспечить уникальность запроса, то вам нужно место для сохранения третьего параметра, который был запрошен.timestamp, если объем запросов большой и выполняется долго, то поддерживать эту штуку точно начнутся хлопоты. С временными метками есть время истечения, если оно превышает установленное значение, его можно сразу выбросить, чтобы снизить затраты на обслуживание и хранение 😜

image.png

В заключение

Подытожим роль трех вышеперечисленных параметров.

  1. Гарантия уникальности для каждого запроса
  2. Предотвратить изменение параметров
  3. Убедитесь, что запрос является законным и исходит от аутентифицированного пользователя.

Вот почему нам нужна проверка подписи параметров 😵

На этом статья заканчивается. Из-за нехватки времени вторая статьяOpenFeignКак реализовать аутентификацию подписи параметра интерфейсаПродолжим завтра👻, спасибо за вашу поддержку и ободрение.


Если статья была вам полезна, добро пожаловать点赞,评论,关注,收藏,分享, ваша поддержка является движущей силой моего кода, большое спасибо! ! ! 🌈

Если есть ошибка в содержании статьи, добро пожаловать на исправление и обмен, спасибо 😘

Ссылка на ссылку