Бытовая техника конечно бред — это не предмет первой необходимости(если это конечно не стиралка/холодильник в семье где несколько человек). Но вот большинство машин в развитых странах почему-то покупают с помощью автокредитов. Это удобно и порой ещё и выгодно.
GSM-момед + DynDNS и проблем никаких. А можно по таймеру проверять почтовый ящик/ленту твиттера/файл на удалённом хосте. Способов передать команду 10001
3.5' джек конечно полезная штука, но я от объективно им ни разу не пользовался. Беспроводные наушники рулят — удобно же. А тем кому прям вот необходим кристально-чистый звук (любителям таскать с телефоном наушники стоимостью в два а то и три телефона) я бы посоветовал воспользоваться чем-то что действительно способно этот звук обеспечить — Cowon какой-нибудь. Сам таким был — переболел.
Но то, что джек есть это хорошо потому что почему бы и нет — кому-то он наверняка необходим.
По поводу сканера внизу экрана — им бы теперь учесть мнения тех кто привык к сканеру на задней панели. Хотя, при наличии сканера сетчатки не так уж он и нужен вообще.
Я ещё помню когда тоже самое писали — про самсунг S8 — «для меня самсунг закончился на S7, чей датчик отпечатков находится на кнопке внизу экрана», а для кого-то самсунг закончился на кнопочных телефонах — все эти тачскрины и прочее — кто это будет использовать. Собаки лают — караван идёт.
Ключ один. А токенов может быть много — для веба, для андроид и иос приложений. У каждого токена может быть своя область видимости а так же время действия. Зачем всё это хранить непонятно. Ключ нужно хранить в любом случае.
Ну тут два пути:
1. Можно всех пользователей по очереди перебирать с их ключами и к какому подойдёт того и пускать в систему.
2. Можно из payload'а извлекать уникальный айди, по нему находить пользователя, получать его ключ и проверять валидность токена. Так все и делают, кстати.
У каждого юзера свой криптоключ для подписи токена. Если один из токенов скомпрометирован — меняем ключ и все токены автоматом становятся невалидные. Пользователю нужно заново логинитьcя дабы получить валидный токен.
Токен формируется в процессе логина как результат успешной аутентификации. Токен нигде хранить не нужно — его достаточно подписать и отдать пользователю. При последующих запросах проверяем валидность переданного нам токена. Если токен попадёт в руки злоумышленника то проблема решается так же как и в случае с паролем — смена пароля ведёт к генерации нового ключа для токенов. Все прежде выпущенные токены становятся не валидными.
1. В рамках NDC/DDC можно было, воспользовавшись веб-экзитами, реализовать абсолютно любой интерфейс и функционал. Работа с QR-кодами в сценарии — не проблема и может быть так же реализована в рамках как XFS так и NDC/DDC
2. Для сертификации в МПС абсолютно не нужно предоставлять какие-то данные о протоколе между банкоматом и хостом — это ваша внутренняя кухня. МПС смотрит на EMV логи (между картой и ридером) и на ISO8583(между хостом и МПС). Не могли бы вы рассказать какие всё-таки сложности у вас возникли на этом пути? Можно конечно предположить что вы изобрели велосипед и написали своё собственное EMV-ядро(занятие для сильных духом мужчин), которое так же пришлось сертифачить (ха а ещё обновлять, ежеквартально минимум, в соответствии с новыми требованиями МПС и прочие приятные мелочи которые могут возникнуть с приёмами карт которые укладываются в спецификации mchip/vsdc но реализуют функционал отличный от типовых сценариев). Пабло Чепалич или Томас Фриман из мастеркарда приезжали или они уже на покое?
3. Раз уж ломать все правила то почему не выбрали JAVA/XFS?
Американца Вашего не Chinedu Ike зовут? В Лагосе компания? Тоже делал такой софт под такой же девайс и тоже для нигерийцев. С безопасностью в Африке везде швах. Сейчас в ЮАР сижу в командировке — тут тоже жопа в Йобурге, благо что я Кейптаун уехал через неделю — тут по-спокойней — даже начало казаться что днём могу один гулять в пределах 1км от отеля.
Но то, что джек есть это хорошо потому что почему бы и нет — кому-то он наверняка необходим.
По поводу сканера внизу экрана — им бы теперь учесть мнения тех кто привык к сканеру на задней панели. Хотя, при наличии сканера сетчатки не так уж он и нужен вообще.
1. Можно всех пользователей по очереди перебирать с их ключами и к какому подойдёт того и пускать в систему.
2. Можно из payload'а извлекать уникальный айди, по нему находить пользователя, получать его ключ и проверять валидность токена. Так все и делают, кстати.
2. Для сертификации в МПС абсолютно не нужно предоставлять какие-то данные о протоколе между банкоматом и хостом — это ваша внутренняя кухня. МПС смотрит на EMV логи (между картой и ридером) и на ISO8583(между хостом и МПС). Не могли бы вы рассказать какие всё-таки сложности у вас возникли на этом пути? Можно конечно предположить что вы изобрели велосипед и написали своё собственное EMV-ядро(занятие для сильных духом мужчин), которое так же пришлось сертифачить (ха а ещё обновлять, ежеквартально минимум, в соответствии с новыми требованиями МПС и прочие приятные мелочи которые могут возникнуть с приёмами карт которые укладываются в спецификации mchip/vsdc но реализуют функционал отличный от типовых сценариев). Пабло Чепалич или Томас Фриман из мастеркарда приезжали или они уже на покое?
3. Раз уж ломать все правила то почему не выбрали JAVA/XFS?
Кто то любит приключения. В моем случае это просто командировка в прекрасную страну (почитай про ЮАР) — в Нигерию не поехал бы.