Совсем скоро закончится поддержка PHP7.1, а Вы всё еще поддерживаете старые версии. Зачем?
Я тоже уже давно перешел на php 7.3, но вы не поверите! Какое существует ОГРОМНОЕ количество «легаси» кода на php 4.0 — 5.6. Часто с ним сталкиваюсь. По этому и понизил версию релиза, хотя это было не просто.
Нет. Это статистический метод описанный в другой статье Определение кодировки текста в PHP — обзор существующих решений плюс еще один велосипед ищет последовательности. А описанный здесь метод сравнивает коды символов с таблицами символов (кодовыми страницами), считает каких символов больше и выдает результат. т.е. если больше всего символов из кодовой таблицы CP1251 (windows-1251) — значит это кодировка windows-1251. Грамотность и стиль написания текста не имеет значения.
для чего то предназначены и используются по назначению.
Что бы завершить эти не конструктивные споры, нашел сегодня пару примеров,
как Yandex и Сбербанк используют токены в своих JSON API вы при желании можете найти еще множество примеров.
Дополнил этими примерами свою статью, смотрите после «PS:»
Повторюсь:
Важно понимать, что токены и подписи в API используются часто, естественно на ряду с другими методами защиты. И те кто работает с разного рода API, прекрасно это знают.
Но даже если это не строка, какая разница, передавайте все. что душе угодно в этом параметре, лишь бы вы были уверены, что это авторизированный запрос.
навязываете какое-то дополнительное невнятное поле
А зачем нужен sign? Если это для защиты целостности сообщений, то как бы почему не общепринятый TLS? Если же это для JWT-токена, то почему не общепринятый `Authorization: Bearer`?
TLS не имеет отношения к RPC, это шифрование протокола, а мы наоборот от протокола передачи данных абстрагируемся. JWT вещь отличная, но это это открытый стандарт (RFC 7519) для создания токенов доступа и к RPC тоже никак не относится.
Токен в конечном итоге это некая хешированная строка, как вы ее создадите, по каким стандартам не важно. А передавать то этот токен как то нужно. Для этого параметр «sign», для передачи токен строки или нескольких строк.
Думаю лучше провести идентификацию немного раньше, не разбирая данные, данных может быть очень много, зачем нам тратить ресурсы на их разбор, если это не авторизированный запрос?
Нет, это не аргумент, отвечаю сам себе)))
т.к. не важно где находится параметр «sign», к моменту его поиска в запросе, JSON уже должен быть разобран(
Ничто не мешает передавать идентификатор сессии в params
писал, по этому поводу чуть выше:
«sign» можно добавит только в «params», но в параметрах должны быть данные и помещать туда подпись можно но, мне кажется, не совсем логично.
Думаю лучше провести идентификацию немного раньше, не разбирая данные, данных может быть очень много, зачем нам тратить ресурсы на их разбор, если это не авторизированный запрос?
и «sign» можно добавит только в «params», но в параметрах должны быть данные и помещать туда подпись можно но, мне кажется, не совсем логично.
Переименовали param -> data
Опять, же с точки зрения логики. мы передаем не просто параметры. а данные т.е. data и принимаем не просто результат, а данные т.е. data.
А понятие результат сводится к получению «флага» успех или ошибка и мы будем обрабатывать полученные данные в зависимости от «флага».
т.е. при стандартном подходе логика обработки ответа примерно такая:
вариант 1 success
1. получили ответ
2. есть ли параметр result
3. обрабатываем result
вариант 2 error
1. получили ответ
2. есть ли параметр result
3. если нет — ищем параметр error
4. если есть error — обрабатываем
При моем подходе. примерно так:
вариант 1 success
1. получили ответ
2. есть ли параметр result и он == success
3. обрабатываем data. если нужно
вариант 2 error
1. получили ответ
2. есть ли параметр result и он == error
3. обрабатываем data
Мне кажется, что мой вариант немного логичней, но это не точно)
На самом деле описанным стандартом я пользуюсь и доволен, но у меня закрались сомнения, верна ли моя логика, по этому я потратил вечер, изложил принципы которыми пользуюсь в виде некого альтернативного стандарта и написал данную статью. Цель послушать умных людей. а не навязать свое мнение.
Хотя мои сомнения появились когда я начал делать проект с использованием микро-сервисной архитектуры. А для обмена данными между сервисами есть 2 основных варианта
RPC или Message Bus. Я как раз остановился на RPC. Но может нужен другой стандарт?
Типа: Remote Service Call (Удаленный вызов сервиса)?
Тогда мое творчество можно назвать по другому, типа: JSON-RPS Version 1.0 )
С каких-то древнейших времен повелось, что у процедуры могут быть «параметры» и она возвращает «результат».
Открыли мне глаза, практически. Видимо я не такой старый)
Но для меня результат и получаемые данные, это не одно и тоже.
т.к. результат на запрос мы получаем всегда, даже когда сервер молчит, это все равно результат.
result вы передаете success или ошибку, я не могу результат мапить
в этом и смысл. Хотите мапить result, а его там нет, там error. Естественно, это все проверяется. Но мне показалось логичным, в начале понять, что нужно сделать, т.е.
result = success — обрабатываем данные из data
result = error — реагируем на ошибку, а все данные о ошибке в data
просто отделил сообщение о результате от данных, мне пока кажется это логичным.
мне ничто не мешает передавать session_id (к примеру) как параметр или какой-нибудь X-Auth-Token в заголовке.
да, согласен. но если «общаются» 2 сервера и нужно абстрагироваться от канала?
т.е. мы не знаем, что за канал передачи данных и о заголовках тоже ничего не знаем. А идентифицировать запросы, а в ряде случаев и ответы нужно.
Это и не форвардинг. Это услуга по пересылке сообщения от посетителя к владельцу сайта.
Услуга, кстати востребованная, есть даже платные аналоги.
Вы пишите в статье:
Кроме того, крупные почтовые сервисы, в том числе Mail.Ru, поддерживают белые списки известных форвардеров (known forwarders) — для списков рассылок и других почтовых служб, почта от которых принимается даже в случае нарушения DMARC.
Вот наш сервис и есть «другие почтовые службы».
Кстати, блокировок стало меньше, но часть писем блокируется все равно:
Action: failed
Status: 5.7.1
Remote-MTA: dns; mxs.mail.ru
Diagnostic-Code: smtp; 550 5.7.1 This message was not accepted due to domain
owner DMARC policy (RFC 7489)
Да, Вы правы, «From» тоже подменяем, попробую подправить, может, что то получится.
писал на support@corp.mail.ru, там шлют ссылки на эту статью в том числе. Ни какой реальной помощи. А сервисом formm.ru пользуются более 3500 пользователей mail.ru почты.
Это не 1-2 и даже не 100 человек, можно проявить немного больше внимания, а в идиале в «белый список» внести. Или такого количества пользователей маловато для «белого списка»?
Дело в том, что по умолчанию кодировки IBM866 и MAC-CYRILLIC выключены.
Если вы хотите что бы они определялись их нужно включить:
и нет смысла дублировать фразу:
т.к. количество символов не изменяется и равно количеству уникальных букв «Проверяемыйтекст».
И тесты добавить.
github.com/onnov/detect-encoding
Буду благодарен за помощь.
Я тоже уже давно перешел на php 7.3, но вы не поверите! Какое существует ОГРОМНОЕ количество «легаси» кода на php 4.0 — 5.6. Часто с ним сталкиваюсь. По этому и понизил версию релиза, хотя это было не просто.
Все для чего то предназначены и используются по назначению.
Что бы завершить эти не конструктивные споры, нашел сегодня пару примеров,
как Yandex и Сбербанк используют токены в своих JSON API вы при желании можете найти еще множество примеров.
Дополнил этими примерами свою статью, смотрите после «PS:»
Повторюсь:
Хотел уже было пуститься в аргументированный спор, но не вижу смысла.
Вы для себя все решили. Имеете право.
Возможно) или можно
hash('sha256', $json),
или можно передать JWT token, это же просто строка
Пример готового JWT:
eyJhbGciOiJSUzI1NiIsInR5cCI6IkpXVCJ9.eyJzdWIiOiIxMjM0NTY3ODkwIiwibmFtZSI6IkpvaG4gRG9lIiwiYWRtaW4iOnRydWV9.EkN-DOsnsuRjRO6BxXemmJDm3HbxrbRzXglbN2S4sOkopdU4IsDxTI8jO19W_A4K8ZPJijNLis4EZsHeY559a4DFOd50_OqgHGuERTqYZyuhtF39yxJPAjUESwxk2J5k_4zM3O-vtd1Ghyo4IbqKKSy6J9mTniYJPenn5-HIirE
Но даже если это не строка, какая разница, передавайте все. что душе угодно в этом параметре, лишь бы вы были уверены, что это авторизированный запрос.
Поле не обязательное.
TLS не имеет отношения к RPC, это шифрование протокола, а мы наоборот от протокола передачи данных абстрагируемся.
JWT вещь отличная, но это это открытый стандарт (RFC 7519) для создания токенов доступа и к RPC тоже никак не относится.
Токен в конечном итоге это некая хешированная строка, как вы ее создадите, по каким стандартам не важно. А передавать то этот токен как то нужно. Для этого параметр «sign», для передачи токен строки или нескольких строк.
имел в виду JSON-RSC (Remote Service Call)
Нет, это не аргумент, отвечаю сам себе)))
т.к. не важно где находится параметр «sign», к моменту его поиска в запросе, JSON уже должен быть разобран(
Спасибо! И я считаю, что на вкус и цвет…
писал, по этому поводу чуть выше:
Думаю лучше провести идентификацию немного раньше, не разбирая данные, данных может быть очень много, зачем нам тратить ресурсы на их разбор, если это не авторизированный запрос?
Мешает стандарт.
в стандарте предусмотрено 4 параметра:
и «sign» можно добавит только в «params», но в параметрах должны быть данные и помещать туда подпись можно но, мне кажется, не совсем логично.
Опять, же с точки зрения логики. мы передаем не просто параметры. а данные т.е. data и принимаем не просто результат, а данные т.е. data.
А понятие результат сводится к получению «флага» успех или ошибка и мы будем обрабатывать полученные данные в зависимости от «флага».
т.е. при стандартном подходе логика обработки ответа примерно такая:
вариант 1 success
1. получили ответ
2. есть ли параметр result
3. обрабатываем result
вариант 2 error
1. получили ответ
2. есть ли параметр result
3. если нет — ищем параметр error
4. если есть error — обрабатываем
При моем подходе. примерно так:
вариант 1 success
1. получили ответ
2. есть ли параметр result и он == success
3. обрабатываем data. если нужно
вариант 2 error
1. получили ответ
2. есть ли параметр result и он == error
3. обрабатываем data
Мне кажется, что мой вариант немного логичней, но это не точно)
На самом деле описанным стандартом я пользуюсь и доволен, но у меня закрались сомнения, верна ли моя логика, по этому я потратил вечер, изложил принципы которыми пользуюсь в виде некого альтернативного стандарта и написал данную статью. Цель послушать умных людей. а не навязать свое мнение.
Хотя мои сомнения появились когда я начал делать проект с использованием микро-сервисной архитектуры. А для обмена данными между сервисами есть 2 основных варианта
RPC или Message Bus. Я как раз остановился на RPC. Но может нужен другой стандарт?
Типа: Remote Service Call (Удаленный вызов сервиса)?
Тогда мое творчество можно назвать по другому, типа: JSON-RPS Version 1.0 )
Открыли мне глаза, практически. Видимо я не такой старый)
Но для меня результат и получаемые данные, это не одно и тоже.
т.к. результат на запрос мы получаем всегда, даже когда сервер молчит, это все равно результат.
в этом и смысл. Хотите мапить result, а его там нет, там error. Естественно, это все проверяется. Но мне показалось логичным, в начале понять, что нужно сделать, т.е.
result = success — обрабатываем данные из data
result = error — реагируем на ошибку, а все данные о ошибке в data
просто отделил сообщение о результате от данных, мне пока кажется это логичным.
да, согласен. но если «общаются» 2 сервера и нужно абстрагироваться от канала?
т.е. мы не знаем, что за канал передачи данных и о заголовках тоже ничего не знаем. А идентифицировать запросы, а в ряде случаев и ответы нужно.
Спасибо!
Услуга, кстати востребованная, есть даже платные аналоги.
Вы пишите в статье:
Вот наш сервис и есть «другие почтовые службы».
Кстати, блокировок стало меньше, но часть писем блокируется все равно:
From теперь правильный, что не так?
Вы мне очень помогли, мне достаточно подменять поле Reply-To, а я зачем то еще From подменял, поправил, должно все работать.
Хотя вопрос про «белый список» сохраняется.
писал на support@corp.mail.ru, там шлют ссылки на эту статью в том числе. Ни какой реальной помощи. А сервисом formm.ru пользуются более 3500 пользователей mail.ru почты.
Это не 1-2 и даже не 100 человек, можно проявить немного больше внимания, а в идиале в «белый список» внести. Или такого количества пользователей маловато для «белого списка»?