Здравствуйте, Cyberax, Вы писали:
C>>>SOAP был бы проще, уже почти жалеем, что не выбрали его. Заодно меньше проблем с валидацией схемы данных с ним. S>>Оппа, недописал — есть JavaScript библиотеки с поддержкой WS-ReliableMessaging? C>Оно руками реализуется в несколько строк (на клиенте).
reliable messaging должен поддерживаться обоими сторонами, т.е. это реализация определенных гарантий. Клиент сам по себе не может ничего гарантировать.
Re[23]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Cyberax, Вы писали:
C>Так нету буквы R — Representational. Обычный RPC есть.
C чего это нету?
C>Оно руками реализуется в несколько строк (на клиенте).
А можно убедительную ссылку?
C>У нас модель такая — на нашей платформе пишутся приложения, мы приложениям даём API.
И? Как это противоречит отдаче JavaScript Client Library?
C>Читал. Извиняюсь, что не заметил пример с криптостойким ID — он потерялся на фоне уязвимых примеров. C>Math.random() угадывается из соседней вкладки браузера, например.
Не понимаю. Можно подробнее? Вы предполагаете, что идиот-пользователь откроет параллельно со страничкой клиента, написанной идиотом-программистом, страничку, написанную злоумышленником? И при этом есть какая-то уязвимость в виде XSS, которая позволит злой страничке взаимодействовать с доброй?
Интересно.
C>И подмешивание timestamp'а не решает ничего, так как идентификаторов можно насоздавать заранее тонну.
Ага. И никто не заметит несколько сот тысяч пользователей, созданных заранее?
С учётом даже пятимиллисекундного разрешения, нужно создавать по 200 пользователей в секунду, чтобы успеть перехватить следующего.
C>У Amazon'а примерно такой API есть — его неправильно использовать просто нельзя.
REST?
C>Такими темпами сброс прав надо на каждую операцию будет делать.
Пока причин так делать не видно. Сброс прав при создании нового объекта — вполне естественная вещь, и я не понимаю, почему она вызывает какие-либо проблемы. Сброс прав при переводе несекретного объекта в секретный — минимальное требование безопасности. Во всех остальных случаях (внесение изменений в объект) я не вижу ни самой проблемы, ни её специфики для REST.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[24]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sinclair, Вы писали:
C>>Так нету буквы R — Representational. Обычный RPC есть. S>C чего это нету?
Где там именно Representational?
C>>Оно руками реализуется в несколько строк (на клиенте). S>А можно убедительную ссылку?
Его аналог у нас столько и занял.
C>>У нас модель такая — на нашей платформе пишутся приложения, мы приложениям даём API. S>И? Как это противоречит отдаче JavaScript Client Library?
Свои местечковые библиотеки.
S>Не понимаю. Можно подробнее? Вы предполагаете, что идиот-пользователь откроет параллельно со страничкой клиента, написанной идиотом-программистом, страничку, написанную злоумышленником? И при этом есть какая-то уязвимость в виде XSS, которая позволит злой страничке взаимодействовать с доброй? S>Интересно.
Предположим, что атакующий имеет доступ на уровне пользователя. Он делает страничку, заманивает туда админа. Страничка используется для угадывания seed'а в Math.random'а — работает в IE и FireFox. Угаданный seed отсылается зловредному скрипту на сервере, контролируемом врагом.
Затем враг будет в течение некоторого времени уметь угадывать UUID'ы, которые сгенерирует браузер админа в соседних вкладках. Далее вопрос в том, как админа попросить сделать небезопасное действие.
И это мы ещё не рассматриваем специально зловредные приложения.
C>>И подмешивание timestamp'а не решает ничего, так как идентификаторов можно насоздавать заранее тонну. S>Ага. И никто не заметит несколько сот тысяч пользователей, созданных заранее?
А 100500 документов могут и не заметить. Их ещё и удалить потом можно. Или заметят тогда, когда уже будет поздно.
Ну и опять же, timestamp могут и забыть подмешать.
S>С учётом даже пятимиллисекундного разрешения, нужно создавать по 200 пользователей в секунду, чтобы успеть перехватить следующего.
Да, и что?
C>>У Amazon'а примерно такой API есть — его неправильно использовать просто нельзя. S>REST?
Да.
C>>Такими темпами сброс прав надо на каждую операцию будет делать. S>Пока причин так делать не видно. Сброс прав при создании нового объекта — вполне естественная вещь, и я не понимаю, почему она вызывает какие-либо проблемы. Сброс прав при переводе несекретного объекта в секретный — минимальное требование безопасности. Во всех остальных случаях (внесение изменений в объект) я не вижу ни самой проблемы, ни её специфики для REST.
Ну вот второй пример — создали объект "документ" (с метаданными), а вторым запросом установили для него содержимое. Нужно ли сбрасывать права при втором запросе?
Sapienti sat!
Re[14]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Большое спасибо за развернутый ответ. Я сейчас только начал делать сайт на MVC для доступа клиента к своим данным на основании авторизации и забитого в users его ID. И читая эту ветку пришел к ужасу по поводу кэширования.
Кстати можешь скинуть ссылку где в MVC прописывать параметры кэширования. http://xmlhack.ru/texts/06/doing-http-caching-right/doing-http-caching-right.html
Понятно что можно через Response.Headers, а может через config прописывать.
А то сейчас кроме работы, еще и MVC http://metanit.com/sharp/mvc/3.5.php изучаю, CSS, Оuery итд. Буду благодарен ссылочкам на русскоязычные сайты. Еще раз спасибо з развернутый ответ.
и солнце б утром не вставало, когда бы не было меня
Re[25]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Cyberax, Вы писали: C>Где там именно Representational?
Вы сначала определите смысл, который вы вкладываете в термин Representational.
C моей точки зрения, транзакция как объект ничем не хуже объекта "счёт".
В большом количестве случаев она есть "и так" в предметной области — например, в финансовом учёте есть понятие "хоз.операция", в которой участвуют оба счёта. Примером операции, затрагивающей более 2х объектов, является ревизия в SVN/CVS. То есть это не просто "синтетическая" штука, придуманная исключительно для обхода проблемы отсутствия WS-Transactions, а первоклассная сущность, со сценариями "дай мне список ревизий" по всяким разным критериям.
В том редком случае, когда вы хотите иметь транзакции, а в предметной области такой сущности, как "ревизия", нету, REST потребует от вас такую сущность ввести искусственно. Считать ли это недостатком — вопрос вкуса. В RPC тоже приходится чем-то жертвовать — ведь, скажем, в "голом" RPC понятия транзакции тоже нету, и её приходится вводить искусственно.
C>Его аналог у нас столько и занял.
Аналог, надо полагать, на REST? Потому что стандартный WS-ReliableMessaging вы ни в несколько строк, ни в несколько тысяч строк на JS не реализуете.
C>Свои местечковые библиотеки.
Не понимаю. Для чего вам "свои местечковые библиотеки"? Такое ощущение, что вы хотите создать проблему, а не решить её.
C>Предположим, что атакующий имеет доступ на уровне пользователя. Он делает страничку, заманивает туда админа. Страничка используется для угадывания seed'а в Math.random'а — работает в IE и FireFox. Угаданный seed отсылается зловредному скрипту на сервере, контролируемом врагом.
Это — хорошая идея.
C>Затем враг будет в течение некоторого времени уметь угадывать UUID'ы, которые сгенерирует браузер админа в соседних вкладках.
Не, не будет. Потому, что к выходу Math.Random() (который сервер врага умеет предсказать) подмешивается timestamp. Заранее неизвестно два параметра:
— когда именно админ соберётся создавать следующего пользователя / документ
— сколько обращений к math.Random произойдёт до создания следующего пользователя/документа.
То есть, грубо говоря, вам нужно взять следующие 100 случайных чисел, взять следующие 720000 таймстампов, и для всех перемешиваний создать пользователей. Т.е. создать 72 миллиона пользователей, чтобы угнать пользователя, которого админ создаст в течение следующего часа. Служба безопасности сервиса должна быть специально подкуплена, чтобы не заметить такую активность. С учётом sensitivity данных, с которыми вы работаете, пользователь наверняка регистрируется не через фейсбук, а достаточно серьёзным способом, подразумевающим возможность идентификации. Так что дальше такого активиста сдаём в отдел К и он садится по статьям 272/273 УК на время, достаточное для гарантии безопасности данных.
C>Далее вопрос в том, как админа попросить сделать небезопасное действие. C>И это мы ещё не рассматриваем специально зловредные приложения.
А какие же вы рассматриваете? Именно что зловредные.
C>А 100500 документов могут и не заметить. Их ещё и удалить потом можно. Или заметят тогда, когда уже будет поздно.
Тогда предотвращайте угон документов при помощи контроля прав. C>Ну и опять же, timestamp могут и забыть подмешать.
Если клиент — идиот, то он всегда может выстрелить себе в ногу. S>>REST? C>Да.
Ну, даже если поверить, что этот API нельзя неправильно использовать (например, тупо храня shared secret в общедоступном месте), то это одно уже доказывает независимость возможности такого API от REST/RPC дилеммы.
C>Ну вот второй пример — создали объект "документ" (с метаданными), а вторым запросом установили для него содержимое. Нужно ли сбрасывать права при втором запросе?
Если вы точно знаете, что новое содержимое (в отличие от старого) является classified, то да. А если нет, то достаточно было сбросить права при первом запросе. Вроде не rocket science?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[16]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Serginio1, Вы писали:
S> Кстати можешь скинуть ссылку где в MVC прописывать параметры кэширования.
Тема сложная, я сходу даже англоязычной статьи про это не нашёл.
В том смысле, что тупое кэширование прикручивается статически на атрибутах, но его полезность меньше нуля.
А что у вас за задача? Чтобы правильно кэшировать, нужно понимать семантику запроса и ответа. В большинстве случаев, имеющих прикладное значение, нужно не "кэширование", а корректная обработка Conditional GET. Вот с ней, к сожалению, всё более-менее плохо. То есть во времена ASP.NET WebForms вроде бы было приемлемое решение (хотя им так и не научились пользоваться), а что является его аналогом для современного MVC я не в курсе.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[15]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Serginio1, Вы писали:
S>Здравствуйте, Sinclair, Вы писали:
S> Большое спасибо за развернутый ответ. Я сейчас только начал делать сайт на MVC для доступа клиента к своим данным на основании авторизации и забитого в users его ID. И читая эту ветку пришел к ужасу по поводу кэширования. S> Кстати можешь скинуть ссылку где в MVC прописывать параметры кэширования. S>http://xmlhack.ru/texts/06/doing-http-caching-right/doing-http-caching-right.html
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Serginio1, Вы писали:
S>> Кстати можешь скинуть ссылку где в MVC прописывать параметры кэширования. S>Тема сложная, я сходу даже англоязычной статьи про это не нашёл. S>В том смысле, что тупое кэширование прикручивается статически на атрибутах, но его полезность меньше нуля.
S>А что у вас за задача? Чтобы правильно кэшировать, нужно понимать семантику запроса и ответа. В большинстве случаев, имеющих прикладное значение, нужно не "кэширование", а корректная обработка Conditional GET. Вот с ней, к сожалению, всё более-менее плохо. То есть во времена ASP.NET WebForms вроде бы было приемлемое решение (хотя им так и не научились пользоваться), а что является его аналогом для современного MVC я не в курсе.
Увы нет такого, надо все руками. Наверное потому что http-cache оказывается app specific, так как зависит от способа узнавания были изменения на сервере или нет. А выставить правильные заголовки — дело трех строк, так что нет смысла прикручивать что-то сверху.
Здравствуйте, Cyberax, Вы писали:
S>>Не понимаю. Можно подробнее? Вы предполагаете, что идиот-пользователь откроет параллельно со страничкой клиента, написанной идиотом-программистом, страничку, написанную злоумышленником? И при этом есть какая-то уязвимость в виде XSS, которая позволит злой страничке взаимодействовать с доброй? S>>Интересно. C>Предположим, что атакующий имеет доступ на уровне пользователя. Он делает страничку, заманивает туда админа. Страничка используется для угадывания seed'а в Math.random'а — работает в IE и FireFox. Угаданный seed отсылается зловредному скрипту на сервере, контролируемом врагом.
Добавьте anti forgery token и будет вам счастье.
Re[26]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, gandjustas, Вы писали:
C>>Предположим, что атакующий имеет доступ на уровне пользователя. Он делает страничку, заманивает туда админа. Страничка используется для угадывания seed'а в Math.random'а — работает в IE и FireFox. Угаданный seed отсылается зловредному скрипту на сервере, контролируемом врагом. G>Добавьте anti forgery token и будет вам счастье.
Как он поможет?
Sapienti sat!
Re[27]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Cyberax, Вы писали:
C>Здравствуйте, gandjustas, Вы писали:
C>>>Предположим, что атакующий имеет доступ на уровне пользователя. Он делает страничку, заманивает туда админа. Страничка используется для угадывания seed'а в Math.random'а — работает в IE и FireFox. Угаданный seed отсылается зловредному скрипту на сервере, контролируемом врагом. G>>Добавьте anti forgery token и будет вам счастье. C>Как он поможет?
Поможет не подделать запрос. Ибо кроме seed нужно будет получить token, а это сможет сделать только аутентифицированный пользователь. Конечно нужна будет проверка прав на сервере.
Re[17]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, gandjustas, Вы писали:
G>У меня статья есть на эту тему, вдруг пригодится: http://gandjustas.blogspot.ru/2013/02/aspnet-mvc.html
Отличная статья. Если я правильно понимаю, то подразумеваемый способ борьбы с conditional Get всё же другой.
У тебя идёт ручное управление кэшированием: ты кладёшь ответ в кэш вручную, и вручную же проверяешь, что там не так.
В теории, вся семантика последующей работы с кэшем уже реализована в самом ASP.NET.
То есть, достаточно выставить респонсу подходящий cacheability, зарегистрировать зависимости в response.AddCacheDependency() (например, зависимость от результата SQL-запроса), и всё будет работать само.
Логика — примерно такая: если приходит запрос на URL, который уже есть в кэше ASP.NET, то кэш его проверяет на предмет валидности, дёргая HasChanged у всех депенденсей, и если всё в порядке, то отдаёт ответ из кэша, не вызывая код контроллера. А если в запросе присутствует If-Modified-Since, то он ещё и отдаёт 304 вместо контента.
К сожалению, на практике я так и не дошёл до полной реализации этого подхода. Если нет подводных камней, то код твоего метода CartSummary должен сократиться в разы.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[18]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, gandjustas, Вы писали:
G>>У меня статья есть на эту тему, вдруг пригодится: http://gandjustas.blogspot.ru/2013/02/aspnet-mvc.html S>Отличная статья. Если я правильно понимаю, то подразумеваемый способ борьбы с conditional Get всё же другой. S>У тебя идёт ручное управление кэшированием: ты кладёшь ответ в кэш вручную, и вручную же проверяешь, что там не так. S>В теории, вся семантика последующей работы с кэшем уже реализована в самом ASP.NET. S>То есть, достаточно выставить респонсу подходящий cacheability, зарегистрировать зависимости в response.AddCacheDependency() (например, зависимость от результата SQL-запроса), и всё будет работать само. S>Логика — примерно такая: если приходит запрос на URL, который уже есть в кэше ASP.NET, то кэш его проверяет на предмет валидности, дёргая HasChanged у всех депенденсей, и если всё в порядке, то отдаёт ответ из кэша, не вызывая код контроллера. А если в запросе присутствует If-Modified-Since, то он ещё и отдаёт 304 вместо контента.
S>К сожалению, на практике я так и не дошёл до полной реализации этого подхода. Если нет подводных камней, то код твоего метода CartSummary должен сократиться в разы.
Я все хочу пост на тему dependency сделать. Увы там много подводных камней, sqldependency я пытался завести целый день. Кроме того, для распределенного кеша надо будет свой cachedependency класс делать, с гораздо более сложным кодом.
Re: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
2/12/2014 12:33 PM, dimgel пишет:
> Дожили. В кои-то веки профильную тему завёл — и ту в КСВ перенесли.
Странный ты. Форум просто в КСВ плавно перетекает, ибо тут осталось
единственное место где можно что-то обсудить, поспорить, столкнутся
взглядами и не очень толерастно.
Posted via RSDN NNTP Server 2.1 beta
Re[19]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, gandjustas, Вы писали:
G>Я все хочу пост на тему dependency сделать.
Было бы здорово. G>Увы там много подводных камней, sqldependency я пытался завести целый день. Кроме того, для распределенного кеша надо будет свой cachedependency класс делать, с гораздо более сложным кодом.
Нутром чую, что можно обойтись без SQLDependency, зато прикрутить linq.
То есть идея — в том, что для для SQL запроса Х автоматически получать запрос Y, который возвращает либо хеш (ETag), либо дату последней модификации (timestamp).
Но это надо подробно прорабатывать.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[20]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sinclair, Вы писали:
G>>Увы там много подводных камней, sqldependency я пытался завести целый день. Кроме того, для распределенного кеша надо будет свой cachedependency класс делать, с гораздо более сложным кодом. S>Нутром чую, что можно обойтись без SQLDependency, зато прикрутить linq. S>То есть идея — в том, что для для SQL запроса Х автоматически получать запрос Y, который возвращает либо хеш (ETag), либо дату последней модификации (timestamp). S>Но это надо подробно прорабатывать.
А поподробнее?
Встроенный SqlCacheDependency — реализация вокруг System.Data.SqlClient.SqlDependency, построенная на polling в отдельном потоке или SQL Notifications. Pooling неинтересен по понятным причинам, а для Notifications много ограничений — http://msdn.microsoft.com/library/ms181122.aspx. SqlCacheDependency вообще позволяет только имя таблицы указать.
Как автоматически сделать из произвольного Linq запроса пригодный для SqlDependeuncy я не представляю. А писать свой CacheDependency класс как-то сложно.
Делать зарос в базу для проверки каждый раз будет крайне неэффективно.
Re[21]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, gandjustas, Вы писали:
G>А поподробнее?
Предположим, мы решаем задачу с нуля — нет ни кэш инфраструктуры, ни Linq, ни MVC.
Как мы будем действовать?
Например, мы можем добавить в интересующие нас таблицы поля LastUpdateTimestamp, оборудованные триггерами на апдейт. Тогда можно понять, изменился ли результат запроса, при помощи select max(LastUpdateTimestamp) from ...
Теперь, посмотрев на такую ручную реализацию, можно попробовать её генерализовать. До linq это было практически нереализуемо, т.к. по тексту стейтмента разобраться, от чего зависит его результат, нереалистично.
А Linq потенциально позволяет нам разобраться во всём.
G>Встроенный SqlCacheDependency — реализация вокруг System.Data.SqlClient.SqlDependency, построенная на polling в отдельном потоке или SQL Notifications. Pooling неинтересен по понятным причинам, а для Notifications много ограничений — http://msdn.microsoft.com/library/ms181122.aspx. SqlCacheDependency вообще позволяет только имя таблицы указать.
Вот именно. G>Как автоматически сделать из произвольного Linq запроса пригодный для SqlDependeuncy я не представляю. А писать свой CacheDependency класс как-то сложно.
Ну вот мне кажется, что должен быть свой. G>Делать зарос в базу для проверки каждый раз будет крайне неэффективно.
Не факт. Во-первых, даже если мы подготовили полный результат, и только теперь убедились, что у клиента такой уже есть, отдать 304 всё ещё лучше с точки зрения трафика. Во-вторых, потенциально запрос, вычисляющий только LastModifiedTimestamp или только ETag может оказаться эффективнее полного запроса. Ну, а главное — альтернативы-то никакой нет. Только если ставить между SQL и кодом приложения какой-то ещё кэш, который поддерживает механизм нотификаций или ещё какой-то метод быстрее выяснить, что некоторый запрос устарел, на основе знаний о привнесённых изменениях.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Re[22]: [давненько мы за REST не срались] Paradigm mismatch is unavoidable!
Здравствуйте, Sinclair, Вы писали:
S>Только если ставить между SQL и кодом приложения какой-то ещё кэш, который поддерживает механизм нотификаций или ещё какой-то метод быстрее выяснить, что некоторый запрос устарел, на основе знаний о привнесённых изменениях.
А это кстати идея. Зачем "между", если можно отдельным слоем в само приложение. Тут неподалёку про DAL и BL спрашивали — так вот у меня есть и то, и другое, и ответственность DAL — как раз кеши (моя вещь, как хочу — так и называю ). Надо будет чутка расширить их функционал.
). Надо будет чутка расширить их функционал.
