Комментарии 46
Из документации не совсем понятно, как подключать безопасность к отдельным страницам (наиболее часто встречающийся кейс). На выбор даны два варианта — одной строчкой но на все страницы (на практике нафиг не нужно) либо в огромное количество строчек вручную для нужных страниц.
Вы сейчас о чем говорите?
О подключении безопасности к приложению. Одностроковый способ:
Работает на все приложение (на все route/страницы) что не есть хорошо. Для установки безопасности на одну страницу (route) нужно очень много строк кода.
Вот интересуюсь, может кто знает с чего такая несправедливость.
use Rack::Auth::Basic do |name, pass| name == 'a' and pass == '1' end
Работает на все приложение (на все route/страницы) что не есть хорошо. Для установки безопасности на одну страницу (route) нужно очень много строк кода.
Вот интересуюсь, может кто знает с чего такая несправедливость.
> Работает на все приложение (на все route/страницы) что не есть хорошо.
и почему это не хорошо?
и почему это не хорошо?
Потому что могут быть страницы доступные публично, а могут быть закрытые. Простой пример — админка.
и вам что, не нужна CSRF защита в админке?
поясню свой комментарий: господин eyeofhell использует rack-protection для HTTP AUTH. сам rack-protection был сделан, чтобы сделать защиту от целого спектра атак на веб-приложения. а HTTP Auth обычно реализовывают немного по-другому.
Если расскажете как в Rack+Sinatra в не очень большое количество строк кода защитить только админку — буду благодарен.
как вам написали ниже, это делается через хелперы. нельзя просто так прописать тот же самый Rack::Auth::Basic для отдельных запросов, потому что это middleware. делайте, как описано в faq.
www.sinatrarb.com/faq.html#auth
www.sinatrarb.com/faq.html#auth
А откуда вы взяли про rack-protection? Я на rack.rubyforge.org/doc/Rack/Auth/Basic.html никакого упоминания не вижу.
точно. почему-то был уверен, что Rack::Auth вынесен в github.com/rkh/rack-protection, а он, оказывается, в core. тем не менее, всё равно это делается только через хелперы
Вы просто запихните авторизация в хелпер и защищайте лишь тебе роуты, которые нужны, вызывая его.
Это тот самый второй способ — много строчек кода. Или есть способ как-то кратко это записать?
много это во сколько? 10 строк это много?
Для DSL — да. Смысл DSL как раз в том, что описывающие конструкции немногословны, описывают саму суть и зрят в корень. Понятно что ручками можно все реализовать. Но ведь весь профит теряется :). Что немного огорчает. Ну раз через хелперы — то через хелперы, мне в принципе все равно.
есть Sinatra, который DSL, а есть Rack, функциональность которого вы используете. зачем мешать одно в другое?
Как уже говорилось, я надеялся, что эту функциональность добрые авторы Sinatra вынесли в DSL как часто используемую. Ну не вынесли и не вынесли, что ж поделаешь :).
часто используемую кем? сейчас люди для авторизации обычно пользуются сессией и красивенькой формой входа. HTTP Auth это как бы прошлый век.
и вообще, не путайте DSL и boilerplate. целью DSL не является описать всю самую используемую функциональность.
и вообще, не путайте DSL и boilerplate. целью DSL не является описать всю самую используемую функциональность.
Если бы в Sinatra добавили часто используемые фичи, то это был бы не DSL, а фреймворк…
А так есть DSL и есть куча надстроек над ним, начиная от sinatra-basic-auth и до Padrino — фреймворка поверх Sinatra.
А так есть DSL и есть куча надстроек над ним, начиная от sinatra-basic-auth и до Padrino — фреймворка поверх Sinatra.
Ну вот как раз по ссылке в комментарие выше приведен пример с методом «protected!», он конечно длиннее одной строчки, но всего один раз надо записать
helpers do
def protected!
unless authorized?
response['WWW-Authenticate'] = %(Basic realm="Restricted Area")
throw(:halt, [401, "Not authorized\n"])
end
end
def authorized?
@auth ||= Rack::Auth::Basic::Request.new(request.env)
@auth.provided? && @auth.basic? && @auth.credentials && @auth.credentials == ['admin', 'admin']
end
end
["/foo", "/bar", "/baz"].each do |path|
get path do
protected!
"You've reached me at #{request.path_info}"
end
end
По идее должно работать :)
Для php Есть F3-фреймворк, для node.js — expressJS в таком стиле… очень удобно для небольших проектов… а так в основном пользуюсь Yii, RoR
лучше бы вы сделали перевод той статьи(точнее серии статей), у которой вы сперли название
> gem install shotgun
вы подключили гем, и при этом не используете его. к вашему сведению, кстати, thin (который по дефолту подхватывается, если установлен) сам перезагружает среду.
вы подключили гем, и при этом не используете его. к вашему сведению, кстати, thin (который по дефолту подхватывается, если установлен) сам перезагружает среду.
Хотелось бы знать насколько просто написать приложение на Sinatra с вложенным формами, кучей связей между моделями, наследованием контроллеров и т.д. ну в общем достаточно сложное приложение. В каких целях лучше применять Sinatra вместо Ruby On Rails? Преимущества Sinatra перед другими Ruby фреймворками для web в чем?
В вашем случае нужно использовать рельсы. Синатра не следует паттерну Модель — Вьюха — Контроллёр. Он является DSL фреймворком. Он не обременён лишним мусором, а предоставляет самое необходимое. Рельсы же, как по мне, монструозны. Сразу оговорюсь, что это лично мое мнение дабы не разжигать спор. Как пример, LinkedIn и Github используют именно Синатру.
Github не юзает синатру. просто многие у них её пилили. а LinkedIn вообще по большей части на Java и Scala.
Насколько я понимаю, Синатра реализует контроллер из триады MVC. Следовать ей в остальном или нет — выбор разработчика. Но по опыту разработки без использования фреймворков для многих задач архитектура как-то сама сводится к MVC. Собственно лет 5 назад я с удивлением узнал, что использую MVC уже лет 5 :)
Использую Sinatra в нескольких проектов со средней нагрузкой (Более миллиона просмотров страниц в сутки). Доволен как слон. Знакомство с ruby, как и все начинал с Rails, но потом осознал, что он слишком монструозен. Зачем мне куча функций в проекте, которыми я не пользуюсь.
Синатра в этом плане идеальный вариант. Подключил необходимые гемы, написал все лаконично благодаря DSL, настроил кластер веб-серверов в связе с nginx. Как результат — все быстро и отлично работает.
Думаю, что слишком много внимания уделяется Rails в руби-сообществе. Синатра хоть и не обладает куче наворотов, но всегда можно подключить необходимый функционал и получить бешеную производительность. И все это при меньшем пороге вхождения в фреймворк и более четкой структурой работы.
Синатра в этом плане идеальный вариант. Подключил необходимые гемы, написал все лаконично благодаря DSL, настроил кластер веб-серверов в связе с nginx. Как результат — все быстро и отлично работает.
Думаю, что слишком много внимания уделяется Rails в руби-сообществе. Синатра хоть и не обладает куче наворотов, но всегда можно подключить необходимый функционал и получить бешеную производительность. И все это при меньшем пороге вхождения в фреймворк и более четкой структурой работы.
Прошу прощения. Промахнулся с ответом. Ниже ответ вам.
Думаю, что слишком много внимания уделяется Rails в руби-сообществе.С другой стороны, это плюс руби перед самым-популярным-в-вебе-языком-сами-знаете-каком. Поверьте на слово, разобщенность сообщества по десятку-другому плюс-минус одинаково популярным фреймворкам играет не на пользу сообщества. Пока есть мэйнстрим, все хотя бы говорят на одном более-менее общем языке, даже если мэйнстримом не пользуются. Опять же перед новичками не стоит проблема выбора. Про меркантильные преимущества даже заикаться не буду.
> В каких целях лучше применять Sinatra вместо Ruby On Rails?
Sinatra хорошо подходит для написания веб-сервисов, когда у вас нет фронтенда в виде веб-интерфейса… Ну самый распространённый пример — флеш-игра в какой-нибудь соц.сети.
Для не слишком больших веб-приложений также имеет смысл присмотреться к Padrino.
Хотя сейчас границы применимости всё больше смешиваются, в том же RoR можно использовать и Rack-вызовы напрямую, и убрать все модули, ненужные для конкретного случая, из контроллера. Т.е. по сути в большинстве случаев это уже дело вкуса… исходя из того, что вам ближе: выпиливание или допиливание, убирать ненужные модули или искать и добавлять нужные.
P.S. Любителям легковесных контроллеров стоит присмотреться к Cells, которые с недавних пор можно использовать и для внешних вызовов.
Sinatra хорошо подходит для написания веб-сервисов, когда у вас нет фронтенда в виде веб-интерфейса… Ну самый распространённый пример — флеш-игра в какой-нибудь соц.сети.
Для не слишком больших веб-приложений также имеет смысл присмотреться к Padrino.
Хотя сейчас границы применимости всё больше смешиваются, в том же RoR можно использовать и Rack-вызовы напрямую, и убрать все модули, ненужные для конкретного случая, из контроллера. Т.е. по сути в большинстве случаев это уже дело вкуса… исходя из того, что вам ближе: выпиливание или допиливание, убирать ненужные модули или искать и добавлять нужные.
P.S. Любителям легковесных контроллеров стоит присмотреться к Cells, которые с недавних пор можно использовать и для внешних вызовов.
Вот именно. Sinatra предоставляет необходимый минимум для того, чтобы постороить на нём неплохое приложение. Также импонирует то, что это DSL фреймворк, предоставляющий гибкую и легковесную платформу для создания веб приложений. Он не является избыточным, как рельсы.
А где использовался шотган? Я так понимаю, что нужно было:
shotgun -p 4567 my_simple_app.rb
shotgun -p 4567 my_simple_app.rb
А есть возможность именовать маршруты. Например как генерировать url имя такую запись
get "/*" do
…
end
get "/*" do
…
end
НЛО прилетело и опубликовало эту надпись здесь
очередная статья которой лучше было бы не быть
1) под виндой? lol u mad?
2) 3-5 скринов а толка на 5 строчек текста.
хватит писать типы для домохозяек, пишите нормальные статьи на полезные и глубокие темы.
1) под виндой? lol u mad?
2) 3-5 скринов а толка на 5 строчек текста.
хватит писать типы для домохозяек, пишите нормальные статьи на полезные и глубокие темы.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Поём вместе с Sinatra. Часть первая. Первое знакомство