А я просто делал свой AuthorizeAttribute где проверял залогинен ли юзер и его роли.
Правда это было давно 2-3 версия, может сейчас что то поменялось. Но работало.
Примерно как тут описано.
Мы сейчас просто пишем проект и там используется самописанный хабра парсер, с хабракатом, спойлером и т.д.
И скоро встанет вопрос имплементации api и я если честно в ступоре в каком формате отдавать и как это всё отображать на моб. клиентах.
На сервере хранится всё в тегах в html тегах + кстомные теги как на хабре <spoiler title="Заголовок">Содержимое</spoiler><youtube>http://...</youtube>
Если бы у хабра был API как бы вам удобней было получать статью?
Получается вам нужно парсить хабр, разбирать спарсеное: на текст, картинки. И потом формировать core text? Не проще было бы засунуть статью в webView?
Тег <code> наверно вообще жёстко парсить? Покажите если не трудно скриншот как отображается статья с вставками кода, нет ios под рукой.
Главную вещь вы так и не решили, все white list sanitizer'ы которые я видел, достаточно хорошо удаляют не нужные теги и чистят атрибуты, но. Допустим мы хотим как на хабре вставить кусок кода, к примеру такой:
<html>
<p>
habrahabr
</p>
</html>
В вашей нынешней реализации, всё что внутри тега source тоже почистится и выведет только надпись habrahabr
Спасибо, что напомнили про чёрный список. Он упоминался в прошлом топике, я про него забыл.
Ещё один маразм. Я вот не понимаю как они могут такое требовать, я бы понял если бы они имели патент на text box и запрещали бы туда вводить некоторые адреса. Почему сторонний разработчик должен плясать подстраивается под их требования. Не обоснованные требования. Формально приложение не содержит пиратского контента, запрещать вводить адреса ещё один маразм.
Я если честно в ступоре, текстом вот так трудно описать на сколько мне эта ситуация кажется абсурдной. Хотя может я чего то не понимаю…
Эпл и Гугл ещё можно понять, им пришла кляуза, что приложение включает пиратский контент, они его заблокировали до разбирательств.
Я не думаю, что Эпл или Гугл заблокировали приложение если бы формулировка кляузы была бы «Возможность вводить адресс пиратского сайта...»
Из статьи так и не понял за что именно заблокировано приложение.
За то что оно в теории может парсить и читать пиратский контент или за ссылки на «пиратские» каталоги книг?
Читать вашей программой можно не только книги, но и любые тексты.
И почему они требуют вашу технологию, это уже какой-то бред. Причём здесь вообще ваша технология понять не могу, она ничего не нарушает и вообще к книгам никакого отношения не имеет, шлите их строго на «Юг».
Скажите, ну зачем вы встроили ссылки на библиотеки, из-за этого все проблемы как я понимаю.
Измените ссылки на site:http://habrahabr.ru qwerty то бишь site:http://{домен-библиотеки}.ru {название-книги} пусть доказывают что поиск по гуглу это плохо.
Как я понимаю Эпл и Гугл или любой другой маркет блокирует приложение если правильно составлена кляуза. Вам пришло какое то уведомление как разработчикам от Эпл за что было заблокировано приложение? Озвучьте его нам.
Понижать рейтинг конечно классно, но в конце концов им будет легче удалить приложение и залить новое, чтоб избавится от негативных комментариев и делать так пока всё не затихнет. Лучше составить текст письма с жалобой на приложение и слать его в support маркетов, заблокированный аккаунт разработчика а вследствие и всех приложений куда продуктивней.
Вы опечатались или не так поняли, как и я в начале. Автор имеет ввиду, что можно рендомно генерить symbol и посылать (каждый раз новый) через type="symbol", тем самым вынуждая выделять память под новый symbol. А так как они не отчищаются Garbage Collector, постепенно они забьют всю памать.
Я имею ввиду, что это косяк рельсов. Зачем разрешать type="symbol" при передаче xml. Вообще зачем разрешать пользователю что то передавать в виде символов, Если я захочу что то за оптимизировать за счёт символов я всегда могу сделать .to_sym
Ох, теперь всё понял. Руби действительно не удаляет символы позволяя тем самым использовать их повторно и более того ещё помещает их в dictionary — Symbol.all_symbols
Я просто вцепился в sql injection и не понял сути второй части поста.
Как это раньше никто не обратил на это внимания?)
Действительно косяк, причём огромный:)
Спасибо за статью
Отключить парсеры и получить не рабочий ajax и api?
Отключения парсеров не решение.
И в чём дос я так понять не могу. При использовании where или .to_s мы предотвращаем описываемую вами проблему.
Выше вы писали:
Просто достаточно 1 компьютера чтобы постепенно забить символами всю память
Но это как бы не правильно или я чего то не знаю?
В руби символы ссылаются на один и тот же кусок памяти если символ уже использовался и память выделилась в отличие от String
Не, то что вы написали имеет смысл, если используется Model.find(), а она судя по книгам и скринкастам используется повсеместно. Хотя в тех же книгах в первых же главах всегда пишут — «Не доверяйте всему, что приходит в приложение из вне...».
Поэтому если используется Model.find(), действительно если передать symbol :all из базы будут забираться все записи, что не очень хорошо.
Так что можно посоветовать как вариани переписать на Model.where(id: id), если не хочется отключать альтернативные парсеры?
Так я к тому и веду, если запрос будет Model.where("id = ?", params[:id]) и к нам придет symbol :all что то произойдет?
У меня ничего не происходит User Load (0.3ms) SELECT "users".* FROM "users" WHERE (id = 'all')
all преобразуется в строку и возвращается пустой масив так как ничего не найдёно.
Разве в 4 рельсах не выпилили сахар вроде find_by? Надо будет использовать where ручками.
Ещё непонятно зачем использовать Model.find_by_id()кода Model.find() и так по id ищет? Или это просто пример для наглядности?
Ну а вообще кто вам мешает написать такое:
Model.find(:all, conditions: ["id LIKE ?", "#{params[:id]}"])
продольные движения прямоугольной головки меньше травмируют десны и лучше очищают по сравнению с вращательными движениями круглой
Это личные наблюдения или мнение стоматолога?
Просто чисто визуально круглые щётки хотя бы видно глазу что они вращаются, прямоугольные(Sonic) такое впечатление что просто от вибрации колеблются.
Сам имел дело только с круглыми Oral-b.
Мне казалось, что такие щётки либо Braun(Oral-b) либо Philips(SoniCare), они давно конкурируют на этом рынке и у них самые топовые щётки если смотреть на кол-во движений в минуту. Есть ли у Omron такой же опыт как у этих компаний?
Ваш выбор обуславливался гироскопом? Можно ли его отключить и регулировать режимы в ручную? Как видно из вашей статьи он мешает, особенно я представляют сколько нервов тратится на балансировку тела с спросони.
У выше перечисленных двух фирм, щётки имеют до 5 режимов, которые можно самому переключать от глубокой чистки до масажа дёсен. Плюс контроль степени нажатия, если будете слишком давить и травмировать эмаль и дёсна, щётка предупредит.
Плюс округлых щёток перед Sonic пока вижу только один, есть куча разных насадок, от простых до отбеливания.
У самого Oral-B Vitality указанная в статье, но это очень старая модель, так что сравнивать с ней не имеет смысла.
А где вы увидели тут стиль c#, тут кода то 3 строчки и все они как по мне в питоньем стиле. Типичное hello world на Django.
Сам сижу на убунте и всё что я тут вижу, хороший редактор, замечательный автокомплит и наверняка дебаг есть.
Деплой в Windows Azure просто опция, ни кто не запрещает взять и задеплоить ручками куда вам угодно.
AuthorizeAttributeгде проверял залогинен ли юзер и его роли.Правда это было давно 2-3 версия, может сейчас что то поменялось. Но работало.
Примерно как тут описано.
Мы сейчас просто пишем проект и там используется самописанный хабра парсер, с хабракатом, спойлером и т.д.
И скоро встанет вопрос имплементации api и я если честно в ступоре в каком формате отдавать и как это всё отображать на моб. клиентах.
На сервере хранится всё в тегах в html тегах + кстомные теги как на хабре
<spoiler title="Заголовок">Содержимое</spoiler><youtube>http://...</youtube>Если бы у хабра был API как бы вам удобней было получать статью?
Тег
<code>наверно вообще жёстко парсить? Покажите если не трудно скриншот как отображается статья с вставками кода, нет ios под рукой.<code>в котором не чистится внутри.В вашей нынешней реализации, всё что внутри тега
sourceтоже почистится и выведет только надписьhabrahabrЕщё один маразм. Я вот не понимаю как они могут такое требовать, я бы понял если бы они имели патент на text box и запрещали бы туда вводить некоторые адреса. Почему сторонний разработчик должен плясать подстраивается под их требования. Не обоснованные требования. Формально приложение не содержит пиратского контента, запрещать вводить адреса ещё один маразм.
Я если честно в ступоре, текстом вот так трудно описать на сколько мне эта ситуация кажется абсурдной. Хотя может я чего то не понимаю…
Эпл и Гугл ещё можно понять, им пришла кляуза, что приложение включает пиратский контент, они его заблокировали до разбирательств.
Я не думаю, что Эпл или Гугл заблокировали приложение если бы формулировка кляузы была бы «Возможность вводить адресс пиратского сайта...»
За то что оно в теории может парсить и читать пиратский контент или за ссылки на «пиратские» каталоги книг?
Читать вашей программой можно не только книги, но и любые тексты.
И почему они требуют вашу технологию, это уже какой-то бред. Причём здесь вообще ваша технология понять не могу, она ничего не нарушает и вообще к книгам никакого отношения не имеет, шлите их строго на «Юг».
Скажите, ну зачем вы встроили ссылки на библиотеки, из-за этого все проблемы как я понимаю.
Измените ссылки на
site:http://habrahabr.ru qwertyто бишьsite:http://{домен-библиотеки}.ru {название-книги}пусть доказывают что поиск по гуглу это плохо.Как я понимаю Эпл и Гугл или любой другой маркет блокирует приложение если правильно составлена кляуза. Вам пришло какое то уведомление как разработчикам от Эпл за что было заблокировано приложение? Озвучьте его нам.
Понижать рейтинг конечно классно, но в конце концов им будет легче удалить приложение и залить новое, чтоб избавится от негативных комментариев и делать так пока всё не затихнет. Лучше составить текст письма с жалобой на приложение и слать его в support маркетов, заблокированный аккаунт разработчика а вследствие и всех приложений куда продуктивней.
type="symbol", тем самым вынуждая выделять память под новый symbol. А так как они не отчищаются Garbage Collector, постепенно они забьют всю памать.type="symbol"при передаче xml. Вообще зачем разрешать пользователю что то передавать в виде символов, Если я захочу что то за оптимизировать за счёт символов я всегда могу сделать.to_symdictionary—Symbol.all_symbolsЯ просто вцепился в sql injection и не понял сути второй части поста.
Как это раньше никто не обратил на это внимания?)
Действительно косяк, причём огромный:)
Спасибо за статью
Отключения парсеров не решение.
И в чём дос я так понять не могу. При использовании
whereили.to_sмы предотвращаем описываемую вами проблему.Выше вы писали:
Но это как бы не правильно или я чего то не знаю?
В руби символы ссылаются на один и тот же кусок памяти если символ уже использовался и память выделилась в отличие от
StringПопробуйте в irb
Model.find(), а она судя по книгам и скринкастам используется повсеместно. Хотя в тех же книгах в первых же главах всегда пишут — «Не доверяйте всему, что приходит в приложение из вне...».Поэтому если используется
Model.find(), действительно если передать symbol :all из базы будут забираться все записи, что не очень хорошо.Так что можно посоветовать как вариани переписать на
Model.where(id: id), если не хочется отключать альтернативные парсеры?Model.where("id = ?", params[:id])и к нам придет symbol :all что то произойдет?У меня ничего не происходит
User Load (0.3ms) SELECT "users".* FROM "users" WHERE (id = 'all')all преобразуется в строку и возвращается пустой масив так как ничего не найдёно.
find_by? Надо будет использовать where ручками.Ещё непонятно зачем использовать
Model.find_by_id()кодаModel.find()и так по id ищет? Или это просто пример для наглядности?Ну а вообще кто вам мешает написать такое:
или так
Это личные наблюдения или мнение стоматолога?
Просто чисто визуально круглые щётки хотя бы видно глазу что они вращаются, прямоугольные(Sonic) такое впечатление что просто от вибрации колеблются.
Сам имел дело только с круглыми Oral-b.
Мне казалось, что такие щётки либо Braun(Oral-b) либо Philips(SoniCare), они давно конкурируют на этом рынке и у них самые топовые щётки если смотреть на кол-во движений в минуту. Есть ли у Omron такой же опыт как у этих компаний?
Ваш выбор обуславливался гироскопом? Можно ли его отключить и регулировать режимы в ручную? Как видно из вашей статьи он мешает, особенно я представляют сколько нервов тратится на балансировку тела с спросони.
У выше перечисленных двух фирм, щётки имеют до 5 режимов, которые можно самому переключать от глубокой чистки до масажа дёсен. Плюс контроль степени нажатия, если будете слишком давить и травмировать эмаль и дёсна, щётка предупредит.
Плюс округлых щёток перед Sonic пока вижу только один, есть куча разных насадок, от простых до отбеливания.
У самого Oral-B Vitality указанная в статье, но это очень старая модель, так что сравнивать с ней не имеет смысла.
Да и самая гиковская и топовая щётки по технологии Sonic это — Philips Sonicare DiamondClean — обзор от SlashGear
Сам сижу на убунте и всё что я тут вижу, хороший редактор, замечательный автокомплит и наверняка дебаг есть.
Деплой в Windows Azure просто опция, ни кто не запрещает взять и задеплоить ручками куда вам угодно.