если я правильно понял, речь про Tampermonkey и подобные.
Судя по отзывам они не очень хорошо работают под мобильными + я не понимаю как они решат задачу.
Да, какие-то действия на страницах можно будет автоматизировать, но у меня проблема в том чтоб JS страницы ни при каких условиях не смог получить реальные window.screen(например), а только тот и те цифры, которые я хочу показать.
*monkey разве позволят изменить readonly-свойства window(screen, navigator etc)?
Да, я смотрел в его сторону, однако он довольно толстый и бесплатный режим не лишен недостатков... Под влиением статьи на хабре я еще смотрел https://commento.io/ но тут проблема с авторизацией... т.е. конечно опенсурс и можно допилить но хочется чтоб полетело с полпинка.
Иван Шумов, да, aws очевидно подойдет... но тут могут начаться вопросы по 152-ФЗ, поскольку тут очевидно нет соответствия... будем искать...
Просто доверия пре-сэйлам нет)
это не секрет)
Просто ПО это один пункт чек листа.
Еще пара пунктов - административные правила...
А еще отдельный набор пунктов - размещение серверов, защита линий связи, физический доступ к серверам. И разрешить эти вопросы без участия хостера мне представляется проблематично, особенно если речь идет про облако.
Дмитрий Шицков, А эффект "отставания" при переключении наблюдался? или galera и её форки решают всеж эту проблему в достаточной степени?
Исходя из логики просто если у нас запись идет на А, а Б в резерве, то в момент когда А упал и арбитр(в схеме с 2мя М-серверами) не все данные могут быть переданы на Б. Опять же интернеты говорят что Галера как-то притормаживает А, и следит за реалтайм соответствием Б... Интересно насколько в реальности это работает или частичная потеря данных при переключении возможна...
Получается что "подписывать" в любом случае будет КриптоПро CSP.
А вот коммутацию наше ПО<->КриптоПро CSP можно осуществить через:
1) КриптоАрм SDK
2) Microsoft Crypto API
3) вызов утилит командрой строки
4) КриптоПро .Net
Natalia Baženova, ну во-первых чем POST аякса хуже CURLовского, учитывая что протокол один)
Во-вторых. Проблему с CORS при отправке заполненной банковской анкеты это не решит.
Сергей, первый запрос в интернет-эквайринге - получение формы. Дальше клиент заполняет данные карты, cvv и тд. и нажимает отправить. И нет ни одного банка который не настроить CORS )) так что если я получу аяксом форму, допустим даже замещу мой код на полученый html, то запрос с данными карт будет с моего домена, что не пропустит ни при каких условиях CORS
банк принимает только POST запросы на открытие своей эквайринговой формы. В качетстве единственного пейлоада- поле с base64 от структуры с разными параметрами.
еслиб можно было просто тупой редирект сделать aka GET-реквест яб был счастлив.
При этом я заметил, что на сайте keycode.info - event.which упорно нереагирует на раскладку... Хотя берут они этот код без каких либо обработок (e.which || '')... у меня же в форме при русской раскладке возращаются коды 1000+...
