Closed Alexsisukin closed 1 year ago
Думаю, имеет смысл оставить нормализацию в тех случаях, когда используется аккаунт Яндекса. То есть, когда логин не содержит доменной части. Чтобы не ломать совместимость с API для финансовых методов. Как ранее обсуждалось в #51
Другое возможное решение, перенести логику нормализации логина туда, где генерируется финансовый токен.
@yethee Спасибо за совет, сделал нормализацию только для аккаунт Яндекса
@yethee пришлось изменить тест \Biplane\Tests\YandexDirect\ConfigTest::testNormalizeClientLogin
так как второй кейс в DataProvider стал не актуальный
Спасибо!
Столкнулся с проблемой когда логин в директе такого вида el.4lekseeva@mail.ru
в результате когда библиотека нормализует логин по правилам и делаю запрос к api получаю ошибку
Объект не найден: В HTTP-заголовке Client-Login указан несуществующий логин
избежать ошибку можно передав в заголовке Client-Login = el.4lekseeva@mail.ru , то есть не измененный нормализациейПоэтому предлагаю дать управление нормализацией логина , что бы можно было отказаться от замены
.
на-
и подобные кейсы обрабатывать на уровне приложения