Вот это единственное верное оправдание для вашего юзкейса с одним сервером. Всё что приведено в статье можно реализовать на одном токене, как верно предложил VasiliySS, и никакой защищённости в этом нет. Ну, разве что refresh token реже отправляется, но если access token живёт 30 минут, то уже через 30 минут злумышленник достигнет своей цели. OAuth2 НЕЛЬЗЯ использовать в незащищённых подключениях, и это ключевое изменение, которое позволило значительно упростить OAuth1.
Из хороших объяснений зачем нужно два ключа я для себя выделил одно:
Использование двух токенов позволяет проверять access token без необходимости хранить его в БД, то есть можно существенно уменьшить нагрузку на БД (избавляемся от одного SQL запроса на каждом HTTP запросе). Как сделать проверку access токена без БД? Элементарно — сервер авторизации должен криптографически подписывать ID пользователя + срок годности токена + случайный текст (то есть access token будет выглядеть как <user_id><expiration_date>), тогда API серверу достаточно проверить цифровую подпись в access token и сверить время жизни, и если всё ОК, то можно считать, что пришёл запрос от пользователя user_id. Очевидный недостаток такого подхода — нельзя отозвать access token, поэтому делают короткоживущий access token и отзывают только refresh token.
Не нужно забивать гвозди микроскопом. Если вам нужно получить абсолютный максимум производительности — не смотрите ни на питон, ни на джаву, ни на пхп, ни на джаваскрипт. Ваши языки — C и может быть C++/Rust. Однако, если ваша задача — внести интерактивность в web-страницу — Javascript (да, есть возможность писать на других языках и транслировать в JS, но ...). Python? Если твоя задача получить результат быстро (не в смысле быстрых рассчётов, а в смысле "на вчера", то Python здесь со своей экосистемой даст возможность этого достичь в кратчайшие сроки, а на C/C++ будете изобретать велосипед, в сотый раз изобретать пакетный менеджер/систему сборки/и прочие базовые утилиты). У большинства инструментов, которыми пользуется больше двух человек есть своя ниша, где они решают задачи эффективнее (быстрее/производительнее/безопаснее/...)
У них есть два режима и они не взаимоисключающие. Можно быстро и бесплатно получить своё приложение на телефоне запустив его через клиент, а можно собрать пакет и опубликовать в стор, тогда и появляется +$100 на iOS и +$50 на Android. Эта идея не нова, как минимум я такое видел для приложений "PhoneGap поколения", например, AppGyver.
XCode и $100 в год на Developer account, чтобы собирать и публиковать приложения
Терпение + Android Studio + SDK + Эмулятор
Можно немного срезать угол, по крайней мере на этапе прототипирования, если использовать Exponent:
Exponent lets web developers build truly native apps that work across both iOS and Android by writing them once in just JavaScript.
It's open source and free and uses React Native.
NavigationExperimental уже эволюционировал в https://reactnavigation.org/ "Learn once, navigate anywhere". Я не знаю всей истории, но похоже, что это будет рекомендованным решением (сейчас он на этапе беты).
бывают сложные сценарии, когда нужно дергать последовательность ручек, вот отсюда из ответа надо взять ИД и передать сюда итд.
В таком случае всё сведётся либо к добавлению упрощённого метода, либо к написанию текста к описанию этих сложных посладовательных методов с подсказками и примерами, ровно так же, как это нужно делать и в классической документации, разве нет?
На мой взгляд, HATEOAS — это ужас ужасный. Из Swagger конфигурации можно получить статический клиент, и после этого взаимодействие сводится к обмену полезными данными, в то время как HATEOAS всё время будет слать кучу информации "на всякий случай". Чтобы был хоть какой-то выигрыш HATEOAS, клиент должен быть динамическим, принимающим какие-то решения в процессе взаимодействия, а если клиент декларативный, то пользы, по-моему, никакой. Мне нравится вот это описание: "А нужен ли мне HATEOAS?"
Я не могу сказать, что Swagger идеален, но мне интересно что же стало его заменой в Вашем случае?
Для моих задач Swagger справляется на 4+. Давайте пройдёмся по вашим пунктам:
"Уродливая система объявления" — похоже, что все описанные раздражающие вещи уже исправлены. Честно говоря, 40-50 методов руками генерировать и потом поддерживать — это сурово, я вот не знаю как автор поддерживает Swagger описания отдельно от своего кода. Я пришёл к тому, что сервер должен строить swagger.json на основании кода, на эту тему у меня есть демо-сервер — https://github.com/frol/flask-restplus-server-example
Я не могу сказать, что я ежедневно использовал онлайн редактор, но ни разу он не вылетел у меня за последний год.
Наверно, тоже исправлено, так как я ежедневно пользуюсь Swagger-UI — полёт нормальный, в том числе в Хроме.
Базовая поддержка OAuth2 в Swagger-UI была добавлена осенью, а около месяца назад наконец добавили и OAuth2 Password Flow
Что значит "пустые роуты"? Сейчас Python генерация вполне себе сносная (я даже недавно сделал её ещё более "Pythonic", но релиза не было с лета, это да… я мастер ветку использую — полёт нормальный)
Итого, единственный актуальный "камень в огород" Swagger — это практически отсутствующая поддержка различных способов авторизации (в Swagger-UI они наконец хоть что-то полезное добавили, но в кодогенерациях даже с поддержкой OAuth2 тухло, так что приходится патчить, но я надеюсь найти немного времени и прикрутить поддержку OAuth2 для Python и JS, которыми я активно пользуюсь и сейчас у меня накладываются не самые изящные патчи)
Мне вот всегда было интересно, приносит ли какое-то удовлетворение создание таких вот "чудо-сервисов для кулхацкеров и прочей нечисти"? В ВК, в частности, репостни-и-выиграй и котики составляют 99% всех записей, и этот % уверенно движется к 99.999%.
Вы абсолютно правы, я знаком с asyncio, да и с остальными async инструментами, сугубо теоретически, причём именно из-за озвученной вами проблемы — нужно всё переписать чтобы сделать что-то маломальски пользователе-ориентированное. Раз вы говорите, что всё так плохо, то, видимо, автору нужно приоритезировать решение этой проблемы.
Справедливости ради, если всё остальное в норме, то можно сказать, что работа с БД просто ещё не реализована правильно… и этот частный, хоть и частый случай, по-моему можно таки продумать более детально чуть позже (естественно, до того как предлагать применять в продакшене).
Браво! Я просто не могу подобрать слов! Тема WebSockets в Python для меня была просто пыткой, сколько я ни пытался заставить себя погрузиться в неё, всё время какое-то отторжение происходило и я быстро находил на что отвлечься. aiorest-ws (по крайней мере по примерам и описанию) — это огромный шаг в сторону упрощения.
Ваша реализация в стиле Flask мне импонирует, как и использование REST подхода. Swagger (OpenAPI) вам не факт, что поможет в плане какой-то готовой реализации (по крайней мере я не слышал о REST WebSockets поддержке ни в Swagger-UI, ни в Swagger-Codegen), но для HTTP RESTful API он просто божесвеннен, на мой взгляд, и я даже собрал демо на Flask-RESTplus (фреймворк для HTTP REST Swagger API) для более-менее жизненного примера, может что-то интересное для себя и в нём найдёте.
Кстати, а ваш роутинг можно на модули разбивать, например, как Blueprint в Flask? Это гораздо удобнее, на мой взгляд, чем один общий router где-то там в корне проекта.
Я вижу, что ваши сериализаторы очень похожи на Marshmallow, но почему бы просто не взять сам Marshmallow вместо нового велосипеда? Неужели требование к минимальности зависимостей настолько строгое?
sed uses the posix basic regular expression syntax. According to the standard, the meaning of some escape sequences is undefined in this syntax; notable in the case of sed are |, +, \?, `, \', \<, >, \b, \B, \w, and \W.
As in all GNU programs that use posix basic regular expressions, sed interprets these escape sequences as special characters. So, x+ matches one or more occurrences of ‘x’. abc|def matches either ‘abc’ or ‘def’.
…
In addition, this version of sed supports several escape characters (some of which are multi-character) to insert non-printable characters in scripts (\a, \c, \d, \o, \r, \t, \v, \x). These can cause similar problems with scripts written for other seds.
Так что \d в GNU sed просто значит не то, что это значит в Perl и многих других реализациях парсеров регулярных выражений. Рекомендуют использовать либо явно [0-9], либо [[:digit:]].
Спасибо за статью! А можно где-то готовую .apk получить? Я с интересом слежу за Kivy (и Python — это мой любимейший ЯП), но скорость загрузки приложения у него хромала последний раз когда я его пробовал, так что ваша фраза:
Используя в своих проектах библиотеку KivyMD плюс немного фантазии, вряд ли кто-то сможет визуально отличить, написана ли ваша программа на Java или с использованием фрейворка Kivy и Python.
вызывает у меня определённые сомнения в честности всего материала.
Go реализовал свою собственную libc, на сколько мне известно (я мало имею отношения к Go, так что это на правах сведений из статей, которые я когда-то читал).
Это не совсем так. Go приложения могут работать на scratch (нулевом) образе, то есть без дистрибутива совсем. Однако, JVM, в отличие от Go, требует libc, так что совсем без "системных файлов" не выйдет и, опять-таки, собрать образ с минимально необходимым списком файлов тоже можно, но в итоге это получается достаточно муторная работа, которая в случае с рассматриваемым вариантом базирования на Alpine Linux даст выигрыш в < 5МБ при том, что урезанная Oracle JDK весит ~160МБ, а полная — ~340МБ.
Ага, будет, как только вы дождётесь загрузки приложения (от 5 секунд идёт загрузка на моих планшете и телефоне). Для собственного пользования оно ещё куда ни шло, но у «обычного пользователя» столько терпения не будет.
Вот это единственное верное оправдание для вашего юзкейса с одним сервером. Всё что приведено в статье можно реализовать на одном токене, как верно предложил VasiliySS, и никакой защищённости в этом нет. Ну, разве что refresh token реже отправляется, но если access token живёт 30 минут, то уже через 30 минут злумышленник достигнет своей цели. OAuth2 НЕЛЬЗЯ использовать в незащищённых подключениях, и это ключевое изменение, которое позволило значительно упростить OAuth1.
Из хороших объяснений зачем нужно два ключа я для себя выделил одно:
Использование двух токенов позволяет проверять access token без необходимости хранить его в БД, то есть можно существенно уменьшить нагрузку на БД (избавляемся от одного SQL запроса на каждом HTTP запросе). Как сделать проверку access токена без БД? Элементарно — сервер авторизации должен криптографически подписывать ID пользователя + срок годности токена + случайный текст (то есть access token будет выглядеть как <user_id><expiration_date>), тогда API серверу достаточно проверить цифровую подпись в access token и сверить время жизни, и если всё ОК, то можно считать, что пришёл запрос от пользователя user_id. Очевидный недостаток такого подхода — нельзя отозвать access token, поэтому делают короткоживущий access token и отзывают только refresh token.
Ваше умозаключение верно и для refresh_token. Перехватив regresh_token — можно сколько угодно раз получать новые пары access + refresh токенов.
Не нужно забивать гвозди микроскопом. Если вам нужно получить абсолютный максимум производительности — не смотрите ни на питон, ни на джаву, ни на пхп, ни на джаваскрипт. Ваши языки — C и может быть C++/Rust. Однако, если ваша задача — внести интерактивность в web-страницу — Javascript (да, есть возможность писать на других языках и транслировать в JS, но ...). Python? Если твоя задача получить результат быстро (не в смысле быстрых рассчётов, а в смысле "на вчера", то Python здесь со своей экосистемой даст возможность этого достичь в кратчайшие сроки, а на C/C++ будете изобретать велосипед, в сотый раз изобретать пакетный менеджер/систему сборки/и прочие базовые утилиты). У большинства инструментов, которыми пользуется больше двух человек есть своя ниша, где они решают задачи эффективнее (быстрее/производительнее/безопаснее/...)
У них есть два режима и они не взаимоисключающие. Можно быстро и бесплатно получить своё приложение на телефоне запустив его через клиент, а можно собрать пакет и опубликовать в стор, тогда и появляется +$100 на iOS и +$50 на Android. Эта идея не нова, как минимум я такое видел для приложений "PhoneGap поколения", например, AppGyver.
Можно немного срезать угол, по крайней мере на этапе прототипирования, если использовать Exponent:
NavigationExperimental уже эволюционировал в https://reactnavigation.org/ "Learn once, navigate anywhere". Я не знаю всей истории, но похоже, что это будет рекомендованным решением (сейчас он на этапе беты).
В таком случае всё сведётся либо к добавлению упрощённого метода, либо к написанию текста к описанию этих сложных посладовательных методов с подсказками и примерами, ровно так же, как это нужно делать и в классической документации, разве нет?
На мой взгляд, HATEOAS — это ужас ужасный. Из Swagger конфигурации можно получить статический клиент, и после этого взаимодействие сводится к обмену полезными данными, в то время как HATEOAS всё время будет слать кучу информации "на всякий случай". Чтобы был хоть какой-то выигрыш HATEOAS, клиент должен быть динамическим, принимающим какие-то решения в процессе взаимодействия, а если клиент декларативный, то пользы, по-моему, никакой. Мне нравится вот это описание: "А нужен ли мне HATEOAS?"
Я не могу сказать, что Swagger идеален, но мне интересно что же стало его заменой в Вашем случае?
Для моих задач Swagger справляется на 4+. Давайте пройдёмся по вашим пунктам:
Итого, единственный актуальный "камень в огород" Swagger — это практически отсутствующая поддержка различных способов авторизации (в Swagger-UI они наконец хоть что-то полезное добавили, но в кодогенерациях даже с поддержкой OAuth2 тухло, так что приходится патчить, но я надеюсь найти немного времени и прикрутить поддержку OAuth2 для Python и JS, которыми я активно пользуюсь и сейчас у меня накладываются не самые изящные патчи)
Вашу бы энергию, да в доброе русло...
Мне вот всегда было интересно, приносит ли какое-то удовлетворение создание таких вот "чудо-сервисов для кулхацкеров и прочей нечисти"? В ВК, в частности, репостни-и-выиграй и котики составляют 99% всех записей, и этот % уверенно движется к 99.999%.
Вы абсолютно правы, я знаком с asyncio, да и с остальными async инструментами, сугубо теоретически, причём именно из-за озвученной вами проблемы — нужно всё переписать чтобы сделать что-то маломальски пользователе-ориентированное. Раз вы говорите, что всё так плохо, то, видимо, автору нужно приоритезировать решение этой проблемы.
Справедливости ради, если всё остальное в норме, то можно сказать, что работа с БД просто ещё не реализована правильно… и этот частный, хоть и частый случай, по-моему можно таки продумать более детально чуть позже (естественно, до того как предлагать применять в продакшене).
Браво! Я просто не могу подобрать слов! Тема WebSockets в Python для меня была просто пыткой, сколько я ни пытался заставить себя погрузиться в неё, всё время какое-то отторжение происходило и я быстро находил на что отвлечься. aiorest-ws (по крайней мере по примерам и описанию) — это огромный шаг в сторону упрощения.
Ваша реализация в стиле Flask мне импонирует, как и использование REST подхода. Swagger (OpenAPI) вам не факт, что поможет в плане какой-то готовой реализации (по крайней мере я не слышал о REST WebSockets поддержке ни в Swagger-UI, ни в Swagger-Codegen), но для HTTP RESTful API он просто божесвеннен, на мой взгляд, и я даже собрал демо на Flask-RESTplus (фреймворк для HTTP REST Swagger API) для более-менее жизненного примера, может что-то интересное для себя и в нём найдёте.
Кстати, а ваш роутинг можно на модули разбивать, например, как Blueprint в Flask? Это гораздо удобнее, на мой взгляд, чем один общий
routerгде-то там в корне проекта.Я вижу, что ваши сериализаторы очень похожи на Marshmallow, но почему бы просто не взять сам Marshmallow вместо нового велосипеда? Неужели требование к минимальности зависимостей настолько строгое?
Просто для домоSEDов, вот справка из официальной документации:
Так что
\dв GNU sed просто значит не то, что это значит в Perl и многих других реализациях парсеров регулярных выражений. Рекомендуют использовать либо явно[0-9], либо[[:digit:]].Удалено
Спасибо за статью! А можно где-то готовую .apk получить? Я с интересом слежу за Kivy (и Python — это мой любимейший ЯП), но скорость загрузки приложения у него хромала последний раз когда я его пробовал, так что ваша фраза:
вызывает у меня определённые сомнения в честности всего материала.
Go реализовал свою собственную libc, на сколько мне известно (я мало имею отношения к Go, так что это на правах сведений из статей, которые я когда-то читал).
Это не совсем так. Go приложения могут работать на
scratch(нулевом) образе, то есть без дистрибутива совсем. Однако, JVM, в отличие от Go, требует libc, так что совсем без "системных файлов" не выйдет и, опять-таки, собрать образ с минимально необходимым списком файлов тоже можно, но в итоге это получается достаточно муторная работа, которая в случае с рассматриваемым вариантом базирования на Alpine Linux даст выигрыш в < 5МБ при том, что урезанная Oracle JDK весит ~160МБ, а полная — ~340МБ.Ничего 100% подходящего не нашлось, так что взял просто самое стабильное решение с пробрасыванием порта — OpenVPN.