АР
Если API правильно спроектировано с точки зрения секьюрности, то зачем скрывать схему?
Size: a a a
2018 July 02
АР
Вот, например, у GitHub сейчас GraphQL API, его каждый пытается тыкать, но они же не скрывают схему.
Nl
Потому что публичное API можно ограничивать как угодно, хоть таймауты по 1 секунде хоть бан через 30 реквестов, свой же родной фронт ограничивать нехорошо
АР
Nl
Да, это уже лучше, спасибо большое, ещё бы этот WhiteList собирался бы на этапе компиляции с продовскими флагами…
АР
Nl
Да, я понимаю, но это всё ещё костыли, нет?
АР
Эмм… почему костыли?
АР
Наоборот, это более правильный и цивилизованный способ ограничить API, чем просто пытаться скрыть introspection.
АР
Это как с криптографией. Надёжен тот шифр, у которого и алгоритм, и публичный ключ не скрывается.
АР
Все знают как он устроен, а взломать не могут, пока не подберут закрытый ключ, что почти нереально.
АР
В таком шифре можно быть уверенным, тут нечего скрывать.
А вот шифры, алгоритм которых тщательно скрывается, сомнительны. Потому что сразу возникает мысль, раз скрывают, значит не идеален. Значит по алгоритму можно найти брешь.
А вот шифры, алгоритм которых тщательно скрывается, сомнительны. Потому что сразу возникает мысль, раз скрывают, значит не идеален. Значит по алгоритму можно найти брешь.
Nl
Ну, у меня просто Банк, и нас беспокоит пользовательская свобода, мы бы хотели графQL- ную гибкость при разработке фронтов и абсолютно детерменированные запросы в проде
Nl
Да, я понимаю, но это всё ещё костыли, нет?
Ну, то есть, это всё клёво, и можно, и нужно использовать, но оно решает не все проблемы
АР
Конкретный список проблем, пожалуйста, в студию. )
АР
АР
Но это не реальная защита, а просто своего рода обфускация.
АР
Так как приватный ключ всё равно на клиенте. )