Pull to refresh
135
0
Алексей @alexkbs

Инженер-программист

Send message

В основном не поменялся.

Сразу скажу что прочитал по диагонали. Замечу только одну вещь: за последний год-два очень сильно изменился ландшафт безналичных платежей. По крайней мере, в центральной части Японии (Токио-Осака). Если раньше, да, действительно, без наличных было никуда, то сейчас даже в таких местах как Сайдзерия или Макдак принимают кредитки. А уличные вендоры может быть кредитки не принимают, но принимают PayPay. И так далее.

По итогу у меня в кошельке может быть одна бумажка 1000 иен лежит уж совсем на крайний случай. И я не помню когда в последний раз она мне была нужна.

Присоединяюсь к сказанному выше abak. От себя хочется позанудствовать что работа с такой моделью не имеет смысла без бенчмарка, что для портфеля акций обычно — биржевой индекс. Если автор попробует свои модели на исторических данных (раньше это было удобно делать на Quantopian, сейчас не знаю), то он может обнаружить что чуда не случилось.

Спасибо, это отличная новость!


Может быть вы ещё порадуете: в целях интеграционного тестирования было бы здорово в тестовом магазине при оформлении платежа иметь возможность указать, куда должны уходить уведомления об этом конкретном платеже.


Например, если тестовые версии разворачиваются на хосте staging.adc83b19e.example.com, где adc... случайный набор цифр, то в текущей схеме получать уведомления с тестового магазина без, опять же, большого количества действий, с настройкой прокси, который будет знать какие именно хосты сейчас используются, не получается. Если бы можно было указать куда должны уходить уведомления для конкретного тестового платежа, то проблема уведомлений была бы решена.


Для настоящих платежей такое, конечно, не требуется.

Уведомления реализовать не проблематично, проблематично тестировать всё это. Приходится делать много жестов руками, опрашивать статус транзакции, и всё это.


Давайте вернёмся к тому скриншоту, где написано что платеж прошел. У него есть две проблемы, одна из них — что человек не возвращается обратно на сайт. Другая проблема в том, что сообщение, которое передаёт эта страница, вводит в заблуждение. На момент, когда человек видит это сообщение, в большинстве случае платеж ещё не прошел.


Рассмотрим практическую ситуацию. Менеджер магазина ввёл в карточке товара какие-то не такие данные, на работу с которыми настроена касса. Или ввёл просто не те данные. Так или иначе, чек сделать удаётся. Но клиент видит что платеж прошел, и начинает переживать. Надо ли говорить что это ни разу не прекрасно. Собираетесь ли вы делать что-то с этой проблемой, если уж не с первой?


Например, можно всё-таки поменять текст на менее категоричный, и более настойчиво отправить человека на сайт. А уж на сайте магазина можно и про ошибку написать, и статус платежа опросить. Угодить уважаемому клиенту. Как вы считаете?


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

То есть, вы говорите, если нужно, чтобы всё было гладко, без уведомлений, как у Stripe и PayPal, то нужно использовать не-редиректный сценарий? Это который, для которого надо дорогую сертификацию по PCI DSS проходить?..


Это, конечно, очень здорового, но это не то, что можно серьёзно предлагать малому бизнесу. Получается у нас патовая ситуация: использовать то, что работало бы чётко и гладко, нельзя, потому что дорого, а использовать то, что работает строго с уведомлениями, не имеет смысла потому что старое работает точно так же. Понимаете о чём я?

После оплаты человек видит что-то такое:



Это не я придумал такое, это из документации: https://kassa.yandex.ru/pay_by_yandex/


Какая у человека должна быть мотивация возвращаться на сайт с такого экрана? Да никакой, вот люди и не возвращаются. Думают, что оплата прошла, все сделано. Не идут по ссылке обратно на сайт магазина. В итоге интеграторы оказываются вынуждены настраивать прием и обработку уведомлений для корректного учета всех платежей.


Вы спрашиваете почему интеграторы не рекомендуют переходить на новое API если уже есть интеграция через старое. Именно потому что это обмен шила на мыло, тут и там прием платежей через уведомления. Так понятно?


Для интеграции платежей через Stripe и PayPal не нужно настраивать прием их уведомлений. Вообще не нужно. В случае Stripe и PayPal процесс оплаты завершается строго после обратного перехода на сайт магазина. Вот если бы с новым API была такая же процедура, это было бы совсем другое дело.


В России Яндекс.Касса — это номер один, но не потому что она какая-то особо хорошая или удобная, а потому что все остальное гораздо хуже. К сожалению.

Спасибо, это очень здорово.


Есть ещё большая проблема, почему новое API не так лучше старого. Сразу скажу что у меня есть проекты, где внедрено и старое, и новое API, и есть множество внедрений Stripe, PayPal и других, так что есть с чем сравнивать, и у меня было такое впечатление что новое API подаёт себя под тем соусом что больше не нужно слушать события, что больше нет этого неудобства номер один в старом API, когда интеграционное тестирование с использованием какого-то временного домена просто невозможно. Создаётся впечатление что новым API должно быть также удобно пользоваться как, например, API Stripe или PayPal (где вообще нет проблем с интеграционным тестированием). Выглядит оно очень похоже, и если бы это было так, это просто прекрасно.


Однако это не так, в новом API тоже необходимо слушать запросы. Например, человек оплачивает с карты, но данные для чека указаны какие-то не такие из-за человеческой ошибки, и чек не создаётся. Но человеку на сайте Яндекс.Кассы показывается сообщение что его платеж принят, и человек не возвращается на сайт, чтобы сайт мог перепроверить факт оплаты, и в итоге и заказ не оплачен, и человек не знает об этом. Никто не рад этому.


Выход из этой ситуации есть: использовать те самые уведомления для проведения платежей. Получается так что полноценное интеграционное тестирование, end-to-end, с новым API тоже невозможно, так как события уходят на фиксированный адрес (что логично само по себе). И получается так что новое API удобно разве что тем, что не нужно сертификаты раз в год заменять. В остальном те же самые грабли. Если вы считаете что здесь есть какая-то мотивация переходить на новое, то, уверяю вас, эта вся ситуация не создаёт ровным счётом никакой мотивации для нас, разработчиков, агитировать или призывать владельцев магазинов переходить на новое API. Мы, наоборот, будет отсоветовать. Старое едва ли хуже.

Это, кстати, то самое достоинство теста, ради которого такой тест можно решить купить. С обычными тестами может показаться что полоска есть, и может показаться что её нет, а может ещё быть так, что из-за индивидуальных особенностей полоска как быть чуть-чуть есть, а на самом деле оснований для второй полоски нет.


Хотя, конечно, надо ещё посмотреть по цене. Может проще купить пачку их обычных двух-трех тестов, если хочется несколько раз через день сделать и убедиться, чем один такой.


(В моей практике не было случая чтобы на момент использования теста и так не было всё ясно просто из срока задержки. Такой способ поставить жирную и толстую точку, только и всего.)

Подумайте так. Возможно, только лишь возможно, именно благодаря системе кармы мы имеем сейчас с вами этот диалог здесь, в комментариях. Здесь, на этом сайте, а не на другом каком-то сайте. Карма определённо поляризует аудиторию и вызывает упомянутые неприятные эффекты с лишением права голоса, но она же и делает сайт, на котором хочется читать и писать, заранее зная что и в статьях, и под статьями будет конструктив.

В старой версии API есть куча интересных данных, вроде части номера карты и эффективной комиссии платежа, которых просто нет в новой. Так бы действительно стоило перейти.

Правильно ли будет сказать что без прошивки схематический дефект (не тот конденсатор...) себя не проявляет?

Тамошним спецслужбам почему-то проблемы не представляет чтобы скоординироваться с коллегами для изъятия серверов в других странах. Даже предположить сложно — как это у них получается.

Домены тамошним спецслужбам не нужно отбирать, достаточно изъять сервера — и всё, есть у вас домен или нет уже не имеет значения. Можно только гадать почему ФСБ теми же мерами обойтись не может.

11 рабочих дней за год положено после полутора лет работы. См. 4.5.8 здесь.

Интересно, что никто в комментариях выше не упоминает подписную модель. Например, платишь $50 в неделю, получаешь возможности играть час-полтора каждый день. Или ещё как. А для вас это будет определённый прогнозируемый доход, на который можно ориентироваться в планировании и вообще.

Надзорных органы нужны, практически, к сожалению. Например, чтобы радиолюбители не запускали радиостанции, которые вещают, например, на частотах метеорологических РЛС. И чтобы потом вместо карты зон осадков мы не наблюдали такое, например. Следить за такими вещами — дело полезное и нужное.


Тем, чем сейчас то самое надзорное ведомство занимается, конечно — не дело.

Не хотелось вас расстраивать, но как раз таки NSA известно продвижением в стандарты мутных генераторов случайных чисел с подозрительными свойствами. К счастью, потом это чудо-юдо из стандартов отозвали. Осадочек остался, вспоминают до сих пор.


(Случайные числа используются, например, в ECDSA, потому если вы можете угадать последовательность случайных чисел, то вы сможете элементарно получить секретную часть ключа, который использовался для подписи. Практический случай. "Свой" генератор случайных чисел как раз в такой ситуации пригодится. Другой частью цифровой подписи является хеш от данных, а значит если вы каким-то образом можете находить интересные коллизии для хешей, например, из функции «Стрибог», то вы сможете подписать что угодно чужим сертификатом. Потому хеш функции вроде Стрибога представляют интересный вектор для внедрения закладок.)

Вы, пожалуйста, определитесь. Автор мог претендовать на бонус по программе bugbounty ЛК, или на что-то от UEFI Forum? На что-то конкретно от последних? Где-то об этом написано?.. Потом, из чего вы делаете вывод что автор не воспользовался программой по уязвимостям от UEFI Forum?.. Судя по статье и комментариям ссылку на ту страницу, откуда вы приводите цитату, автор нашел и именно по этим адресам написал. Именно с этих адресов ему не отвечают.


Вообще же проблема не стоит выеденного яйца, достаточно добавить хеша или сертификата в список отзыва в очередном обновлении, и всё. Да, это неприятно, но выход тут только один.

https://hackerone.com/uefi_forum


There are no known guidelines for reporting potential security vulnerabilities to this organization.

Information

Rating
Does not participate
Location
Кобе, Хиого, Япония
Date of birth
Registered
Activity