Они всегда будут принимать решение на основании содержимого ответа. HATEOAS даёт возможность не плодить v1/v2/v3/v1000, для случаев, когда там просто изменился один URL. Можно «хардокить» везде ссылки и пересобирать мобильные приложение и фронтенд каждый раз, если так удобнее.
Для случая просто смены URL я оставляю старый URL, в документации помечаю deprecated, а в следующей версии, когда других изменений уже накопилось много — удаляю.
Если говорить о каком-нибудь инструменте автоматического генерирования админки, то без HATEOAS там вообще обойтись не получится.
Вы документацию читали? Есть «хуки» на каждое событие, если их их мало, то есть все возможности Flask. Вы же сами дальше пишите, что Flask используете.
Хуки хуками, а бизнес логику куда девать? Её не существует? Самое первое препятствие — роли пользователей, в частности «владелец» объекта и «менеджер», который имеет доступ в том числе ко всем объектам своих подчинённых (в простом случае). Вот так я это реализовал в своём примере — github.com/frol/flask-restplus-server-example/blob/master/app/modules/teams/resources.py#L79
Да, ещё меня в Python Eve удивила реализация PATCH. Please. Don't Patch Like An Idiot. — William Durand. Если кратко, то есть RFC 6902, а в Eve решили придумать свой велосипед. (Кстати, в моём примере RESTful API сервера, по ссылке выше, PATCH реализован как рекомендует RFC)
Как вариант, есть PhotonMail.com. Они предлагают два пароля — один для авторизации, а второй — для шифрования. Шифрование происходит в JS на стороне пользователя и они заявляют, что содержимое писем никогда не отправляется к ним на сервера в открытом виде и расшифровать они его не могут (кстати, поэтому они не могут предоставлять функцию восстановления пароля, так как пароль для шифрования никогда у них не сохраняется ни в каком виде, а значит перешифровать данные они не могут).
Смотрел я на Python Eve некоторое время назад и знаете, у меня был опыт наступания на подобные грабли — Pinax назывались эти грабли. Всё это дело работает до поры до времени, пока у вас какой-нибудь хитрый случай не вылезет, где простым SELECT/UPDATE не отделаешься и начнётся «сладкая жизнь». Это ещё не говоря о том, что dict с конфигом разрастается в реальном проекте мама не горюй и подстветка синтаксиса такому коду уже не поможет.
Кстати, интерфейсы взаимодействия в Eve меня пугают — JSON в GET параметрах выглядит странно, HATEOAS тоже не панацея (люди решили почему-то, что обязательно нужно иметь ссылки в API, но API используют машины и они не будут принимать никаких решений на основании содержимого ответа, они могут составить ссылки самостоятельно, в отличие от «кликающего пользователя»).
P.S. Мои личные поиски «идеального» инструмента завершились на Flask-RESTplus, в котором, пожалуй да, приходится писать чуть больше кода, но зато есть возможность сделать то, что нужно и где нужно. Я в итоге собрал минимальный пример REST API сервера
Я сам всё ещё не успел найти время на TF, но есть tensorflow/skflow (от ilblackdragon), который упрощает API и всё, что вы описали в статье делается в skflow обёртке куда проще.
Я вот почитал про внутреннее устройство vagga и хоть оно и работает без root'a, но требует дырявую CONFIG_USER_NS (Arch Linux поэтому и не включает эту опцию). Так что, похоже, что LD действительно имеет вполне себе нишу и на desktop.
Огромное спасибо meefik за Linux Deploy! Именно благодаря Linux Deploy мой Android трансформер был прекрасной машиной для работы в дороге (батареи хватало на гораздо дольше, чем меня :)). Я успешно настроил себе bash, ssh, vim, python, MySQL, PostgreSQL и Rabbitmq.
Тем не менее, при работе на полноценном Linux нынче есть, например, vagga для случая, когда root нельзя давать ни под каким соусом, а значит Docker уже будет сложнее использовать (хотя можно, наверно, свои обёртки написать, в которых не развенёшься и не запустишь ничего кроме того, что разрешено).
Тема статьи, мне лично, интересна, хоть я и не варюсь в кухне предоставления хостинга. Тем не менее, я интересуюсь разделением ресурсов для задач запуска потенциально опасного кода (в частности, олимпиадное программирование).
У меня вот возникло несколько вопросов:
1. С какой целью используется OpenVZ, ведь вроде бы все квоты вы раздаёте через cgroups?
2. Не могли бы вы сравнить возможности LVE с Docker? (последний тоже изолирует всё через cgroups и виртуальную FS, хотя и есть опция переключиться на LXC)
Неплохой стартовый вариант для размышлений, как мне кажется — www.domjudge.org (я только что на неё набрёл, но прочитав документацию увидел там всё то, что мы используем у себя)
ИМХО, описанные вещи в статье относительно тестирующей системы — это набор костылей и протезов. Не могу оценить, конечно, качество этих протезов, но сдаётся мне, что всё плохо будет если кому-то будет очень скучно и он решит таки убить систему да ещё и с потрохами может её достать. Патчить каждый отдельный компилятор — это ни себе чего задачка.
Так вот, к чему я веду, лучше забудьте об этом пути. Смотрите на современный мир — виртуализация и контейнеризация. У нас в Харькове тоже уже много лет была собственная самописная система только она была более здраво спроектирована, чем описанное решение из статьи, — Web-интерфейс с базой отдельно, а тесты гонялись на других машинах (это и безопаснее, и масштабируется отлично, и просто лучше выглядит с точки зрения дизайна). Ну и да, она очень плотно использовала возможности Linux для всяческих ограничений (время — setitimer, память — ulimit, доступ — chroot, ограничение системных вызовов — патч в ядро). Тем не менее, тестирующая часть из-за непортируемого патча на ядро была слишком сильно завязана на систему и всё равно имела ряд сложностей особенно с добавлением новых языков, так как все их нужно было бы собирать под старую ОС — это опять же связано, как и у авторов статьи с их «возрождённой» тестовой системой, с тем, что тогда альтернатив особо не нашлось.
И вот, наконец, подводя черту, хочу сказать, что мне удалось написать с нуля тестирующую систему, которая максимально использует возможности новых ядер Linux, но без каких-либо патчей, и Docker для управления контейнерами. Все решения запускаются в строго ограниченных контейнерах, из которых (теоретически) выбраться нельзя и всё это дело достаточно производительно работает. При этом каждый компилятор — это просто новый отдельный контейнер, так что добавление компилятора делается крайне просто и при этом все ограничения связанные с безопасностью идут практически из коробки. У нас сейчас уже есть такие языки: C/C++ (GCC), FreePascal, Python 2.7, Python 3.5, Ruby, Go, Haskell, OpenJDK 7, OracleJDK 8, Scala, PHP, C# (mono), Nim, Rust. Вот сегодня успешно провели 30 районных олимпиад одновременно (30 районов Харькова ~= 1000 индивидуальных участников), которые генерировали в среднем 38 решений в минуту (6700 решений за 3 часа). И всё это протестировала одна двухъядерная виртуалка с 1ГБ ОЗУ, а Web UI на PHP с MySQL жили и вовсе на одноядерной VDS (тоже 1ГБ ОЗУ).
Нет, так же как и не ставят автоматически HSTS, так как это может привести к тому, что сайт будет «заблокирован» для посетителей. Например, в случае с HSTS, ввиду их использования HTTP, а для случая с HPKP — если сервер вдруг выйдет из строя, а бекапов не будет.
Я не знаю как они ожидают это проворачивать, я тоже в документации не нашёл, поэтому через исходники нашёл где они хранят virtualenv и поставил туда пакет letsencrypt-nginx:
Ребята усердно работали над этим проектом больше года, я следил и принимал участие в закрытом тестировании. У них несколько компаний в спонсорах, в том числе Facebook. Без HTTPS, или с использованием платных сертификатов (ЦА которых должны соблюдать «требования безопасности» выдвигаемые нормами, вероятно, АНБ) вас АНБ не беспокоило, видимо. Чтобы не беспокоиться за безопасность чего-либо — нужно обесточить и зарыть все данные под землю поближе к мантии.
А вот в /etc/letsencrypt/options-ssl-nginx.conf совсем базовый конфиг, который даёт оценку B на ssllabs.com, так что его я изменил до:
/etc/letsencrypt/options-ssl-nginx.conf
# ciphers chosen for forward secrecy and compatibility
# http://blog.ivanristic.com/2013/08/configuring-apache-nginx-and-openssl-for-forward-secrecy.html
ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:DHE-RSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES256-SHA256:DHE-RSA-AES128-SHA256:DHE-RSA-AES256-SHA:DHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:EDH-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:HIGH:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
# disable SSLv3(enabled by default since nginx 0.8.19) since it's less secure then TLS http://en.wikipedia.org/wiki/Secure_Sockets_Layer#SSL_3.0
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_session_cache shared:SSL:50m;
ssl_session_timeout 1440m;
# enables server-side protection from BEAST attacks
# http://blog.ivanristic.com/2013/09/is-beast-still-a-threat.html
ssl_prefer_server_ciphers on;
# Diffie-Hellman parameter for DHE ciphersuites, recommended 2048 bits: openssl dhparam -out /etc/nginx/ssl/dhparam.pem 2048
ssl_dhparam /etc/nginx/ssl/dhparam.pem;
# config to enable HSTS(HTTP Strict Transport Security) https://developer.mozilla.org/en-US/docs/Security/HTTP_Strict_Transport_Security
# to avoid ssl stripping https://en.wikipedia.org/wiki/SSL_stripping#SSL_stripping
# WARNING: Don't forget to add the following lines to /etc/nginx/conf.d/mapping.conf:
# map $upstream_http_strict_transport_security $strict_transport_security {
# '' max-age=31536000;
# }
add_header Strict-Transport-Security $strict_transport_security;
add_header X-Frame-Options DENY;
add_header X-Content-Type-Options nosniff;
ssl_session_tickets off;
# Requires nginx >= 1.5.9
# enable ocsp stapling (mechanism by which a site can convey certificate revocation information to visitors in a privacy-preserving, scalable manner)
# http://blog.mozilla.org/security/2013/07/29/ocsp-stapling-in-firefox/
resolver 8.8.8.8 valid=300s;
resolver_timeout 300s;
# These are included by letsencrypt to each individual host config
#ssl_stapling on; # Requires nginx >= 1.3.7
#ssl_stapling_verify on; # Requires nginx => 1.3.7
Обращение к читателям: ПОЖАЛУЙСТА, НЕ КОПИРУЙТЕ НАСТРОЙКИ БЕЗДУМНО! Я стараюсь всё комментировать (для себя в первую очередь), поэтому не поленитесь и ознакомьтесь с каждой применяемой опцией.
Я использую Let's Encrypt с Nginx с закрытой Beta ещё — в целом, работает (A+ оценка ssllabs.com), но иногда нужно подготовить конфиги чтобы плагин мог их нормально модифицировать. Например, у меня были другие HTTPS хосты настроены и Let's Encrypt не мог проверить причастность моего домена из-за того, что запросы уходили в другой HTTPS хост (listen domain:443 default;), нужно было всего лишь использовать listen без указания домена/IP-адреса (listen 443 default;). Для переезда с другого SSL сертификата мне проще было закомментировать настройки связанные с HTTPS чтобы Let's Encrypt смог его «обновить с HTTP до HTTPS». Если домен совсем не слушал 80 порт, то конфиг добавится в /etc/nginx/nginx.conf, что тоже заняло некоторое время на выяснение причин происходящих чудес.
Ещё из неприятных особенностей — когда Let's Encrypt патчит конфиги — он их полностью переформатирует — убираются «лишние» пустые строки, отступы становятся строго 4 пробела (для меня это ок), комментарии на одной строке с настройкой разносятся на две строки (получается комментарий к чему-то становится после того, что нужно было прокомментировать).
Ок, оставим C/C++/Rust. Я вписал Go так как он там где-то рядом, если сравнивать с производительностью CPython (ветка началась с него, вот я с ним и сравнивал).
Нечувствительность к регистру и возвращение результата через переменную result — это то, что досталось от Delphi/Pascal. Хоть я и любил Delphi и Pascal в своё время, сейчас же мне кажется, что это не самые лучшие вещи, которые стоило брать в новый язык. Nim в плане философии для меня близок к Ruby — в языке есть 100500 (изощрённых) способов выстрелить себе и тому, кто будет поддерживать написанный код, в ногу.
По The OpenAPI Specification (fka The Swagger Specification) строить админку куда легче, чем ходить по всем URL.
Хуки хуками, а бизнес логику куда девать? Её не существует? Самое первое препятствие — роли пользователей, в частности «владелец» объекта и «менеджер», который имеет доступ в том числе ко всем объектам своих подчинённых (в простом случае). Вот так я это реализовал в своём примере — github.com/frol/flask-restplus-server-example/blob/master/app/modules/teams/resources.py#L79
Да, почему-то в коде мне их удобнее описывать, могу использовать наследования, например: github.com/frol/flask-restplus-server-example/blob/master/app/modules/teams/schemas.py
Кстати, интерфейсы взаимодействия в Eve меня пугают — JSON в GET параметрах выглядит странно, HATEOAS тоже не панацея (люди решили почему-то, что обязательно нужно иметь ссылки в API, но API используют машины и они не будут принимать никаких решений на основании содержимого ответа, они могут составить ссылки самостоятельно, в отличие от «кликающего пользователя»).
P.S. Мои личные поиски «идеального» инструмента завершились на Flask-RESTplus, в котором, пожалуй да, приходится писать чуть больше кода, но зато есть возможность сделать то, что нужно и где нужно. Я в итоге собрал минимальный пример REST API сервера
Тем не менее, при работе на полноценном Linux нынче есть, например, vagga для случая, когда root нельзя давать ни под каким соусом, а значит Docker уже будет сложнее использовать (хотя можно, наверно, свои обёртки написать, в которых не развенёшься и не запустишь ничего кроме того, что разрешено).
В частности, я косвенно помогаю в проекте Kids2IT в Харькове и Харьковской области.
Чем больше умных людей — тем больше перспективы! (… и тем меньше шанс, что наш голубой шарик взорвут балбесы)
У меня вот возникло несколько вопросов:
1. С какой целью используется OpenVZ, ведь вроде бы все квоты вы раздаёте через cgroups?
2. Не могли бы вы сравнить возможности LVE с Docker? (последний тоже изолирует всё через cgroups и виртуальную FS, хотя и есть опция переключиться на LXC)
Так вот, к чему я веду, лучше забудьте об этом пути. Смотрите на современный мир — виртуализация и контейнеризация. У нас в Харькове тоже уже много лет была собственная самописная система только она была более здраво спроектирована, чем описанное решение из статьи, — Web-интерфейс с базой отдельно, а тесты гонялись на других машинах (это и безопаснее, и масштабируется отлично, и просто лучше выглядит с точки зрения дизайна). Ну и да, она очень плотно использовала возможности Linux для всяческих ограничений (время — setitimer, память — ulimit, доступ — chroot, ограничение системных вызовов — патч в ядро). Тем не менее, тестирующая часть из-за непортируемого патча на ядро была слишком сильно завязана на систему и всё равно имела ряд сложностей особенно с добавлением новых языков, так как все их нужно было бы собирать под старую ОС — это опять же связано, как и у авторов статьи с их «возрождённой» тестовой системой, с тем, что тогда альтернатив особо не нашлось.
И вот, наконец, подводя черту, хочу сказать, что мне удалось написать с нуля тестирующую систему, которая максимально использует возможности новых ядер Linux, но без каких-либо патчей, и Docker для управления контейнерами. Все решения запускаются в строго ограниченных контейнерах, из которых (теоретически) выбраться нельзя и всё это дело достаточно производительно работает. При этом каждый компилятор — это просто новый отдельный контейнер, так что добавление компилятора делается крайне просто и при этом все ограничения связанные с безопасностью идут практически из коробки. У нас сейчас уже есть такие языки: C/C++ (GCC), FreePascal, Python 2.7, Python 3.5, Ruby, Go, Haskell, OpenJDK 7, OracleJDK 8, Scala, PHP, C# (mono), Nim, Rust. Вот сегодня успешно провели 30 районных олимпиад одновременно (30 районов Харькова ~= 1000 индивидуальных участников), которые генерировали в среднем 38 решений в минуту (6700 решений за 3 часа). И всё это протестировала одна двухъядерная виртуалка с 1ГБ ОЗУ, а Web UI на PHP с MySQL жили и вовсе на одноядерной VDS (тоже 1ГБ ОЗУ).
Обсуждение: community.letsencrypt.org/t/support-for-hpkp-http-public-key-pinning/504
letsencrypt-nginx:заменится на:
А вот в
/etc/letsencrypt/options-ssl-nginx.confсовсем базовый конфиг, который даёт оценку B на ssllabs.com, так что его я изменил до:Обращение к читателям: ПОЖАЛУЙСТА, НЕ КОПИРУЙТЕ НАСТРОЙКИ БЕЗДУМНО! Я стараюсь всё комментировать (для себя в первую очередь), поэтому не поленитесь и ознакомьтесь с каждой применяемой опцией.
listen domain:443 default;), нужно было всего лишь использовать listen без указания домена/IP-адреса (listen 443 default;). Для переезда с другого SSL сертификата мне проще было закомментировать настройки связанные с HTTPS чтобы Let's Encrypt смог его «обновить с HTTP до HTTPS». Если домен совсем не слушал 80 порт, то конфиг добавится в/etc/nginx/nginx.conf, что тоже заняло некоторое время на выяснение причин происходящих чудес.Ещё из неприятных особенностей — когда Let's Encrypt патчит конфиги — он их полностью переформатирует — убираются «лишние» пустые строки, отступы становятся строго 4 пробела (для меня это ок), комментарии на одной строке с настройкой разносятся на две строки (получается комментарий к чему-то становится после того, что нужно было прокомментировать).
result— это то, что досталось от Delphi/Pascal. Хоть я и любил Delphi и Pascal в своё время, сейчас же мне кажется, что это не самые лучшие вещи, которые стоило брать в новый язык. Nim в плане философии для меня близок к Ruby — в языке есть 100500 (изощрённых) способов выстрелить себе и тому, кто будет поддерживать написанный код, в ногу.Вот есть Benchmark'и: github.com/logicchains/LPATHBench/blob/master/writeup.md
А вот есть статья на хабре сравнивающая Nim vs Rust: habrahabr.ru/post/259993