|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
KGP LSVт.к. почти везде есть критичные дыры, информацию о которых можно найти в инете за 5минут. бред Неужели !? Немалое кол-во дыр есть в ОС, СУБД, приложениях. Многие из дыр хорошо описаны на хакерских сайтах. Там же встречаются методики, коды, эксплойты по проникновению в эту "дыру". Даже страшно читать..... :) Именно поэтому возникла аксиома, что неломаемых программ нет. А смешно то, что систем, удовлетворяющих вышеописанным требованиям - раз два и обчелся. Никто ниодной так и не упомянул. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 14:05 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
LSVА смешно то, что систем, удовлетворяющих вышеописанным требованиям - раз два и обчелся. Никто ниодной так и не упомянул. Это вы про какие требования? Про вот эти: LSVпару известных систем (кроме упомянутого OEBS), где вся безопасность лежит в СУБД ???? Я например, просто не знаю какие системы вы считаете известными. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 14:10 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
Bogdanov AndreyНу на эту же ситуацию можно взглянуть и по другому. Можно. Правда, не знаю, зачем каждому бухгалтеру общий баланс банка, но готов принять как условный пример. Но! Одно дело - контролируемое предоставление доступа к дополнительным полномочиям ("плюс общий баланс банка"), другое дело - тонкое место, которое будет регулярно рваться. Bogdanov AndreyДолжен отметить, что именно такие ситуации постоянно встречаются - для аналитической отчетности почти всегда требуется аггрегаты по более широкому спектру данных, чем доступные для непосредственной работы. Скажу так: те два года, что я работал именно с аналитикой и аналитической отчетностью, постоянно вставала именно задача ограничения доступа ("... и чтоб ни чучелом, ни тушкой не увидел цифр по другому департаменту...") Bogdanov AndreyА вот для оперативной отчетности (когда надо "напечатать" один живущий в СУБД "объект") почти всегда достаточно тех самых стандартных вью, о которых говорит pkarklin. Это да. Но такие отчеты как правило есть в базовой поставке. Bogdanov AndreyВ любом случае, человек, который разработывает отчеты (не знаю, почему его обозвали суперпользователем, если это обычный разработчик) Потому что pkarklin предложил дать этому разработчику привилегию SELECT ANY TABLE (точнее, ее mssql-ный аналог). А это уже никак не "обычный разработчик", если конечно "обычный разработчик" != "дба". Bogdanov Andreyдолжен задуматься о том, каким образом должна сказываться система безопасности на данных, которые его отчет представляет. И никакая RLS здесь не поможет. Вы смотрите с точки зрения разработчика, а посмотрите еще и с точки зрения безопасника. RLS поможет в чем: в том, что для того, чтобы увидеть "недоступные в оперативной работе данные" придется прилагать специальные усилия. То есть действует принцип "запрещено все, что не разрешено". В то же время ее отсутствие приведет к тому, что каждый прямой доступ к объекту будет тонким местом в безопасности. Ну а использование только доступа через вьюхи, при адекватной безопасности будет плохо с точки зрения удобства-скорости. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 14:14 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
softwarerТо есть Вы предлагаете стрелять из пушки по воробьям. Извините, я ничего не предлагал... Я всего лишь указал возможное решение предоставления доступа к физичесим таблицам бд, если система спроектирована без оного: pkarklinнапример, имеет право читать из всех таблиц (например, в MS SQL достаточно включить его в роль бд db_datareader). softwarerПредставьте себе самую обычную камеру хранения; каждый пользователь может подойти, открыть свою ячейку, положить-взять вещи. Это примерно та система, которую полагаю нормальной я. Вы же говорите: не надо давать пользователям прямой доступ к ячейкам. И у меня такая же нормальная камера хранения. Только без прямого доступа к таблицам. Пользователя оперируют другими типами объектов. Физическая модель данных им не доступна. softwarerДавайте лучше заведем кладовщика, который будет осознавать свою ответственность и носить вещи в ячейки и обратно. Для этого мы дадим ему универсальную отмычку, подходящую к любой ячейке. Так вот, лично я вижу в этом следующие недостатки: во-первых, рядовым пользователям неудобно, во-вторых, кладовщик является слабым звеном, может и сам спереть вещи, и оказаться уязвимым для любого постороннего. Я вижу здесь те же недостатки и ни в одной из моих систем, к которых у пользователя нет доступа к таблицам, нет такого кладовщика. И рядовые пользователи могут в пределах своих полномочий пользоваться объектами бд (не таблицами) и я не вижу здесь никаких неудобств. softwarerВо-первых, довольно часто тот, кто разрабатывает отчеты, не должен иметь доступ к "действительно секретной информации". Вы предлагаете наплевать на этот принцип; в результате, чтобы обеспечить это требование, придется извращаться (скажем, делать отдельную базу, выгружать туда часть данных, делать этот отчет там). Повторюсь, я ничего не предлагал. Вы опять додумываете в нужную Вам сторону. softwarerВо-вторых, после того, как ваш суперпользователь сделает отчет, снова вылезает вопрос безопасности, вылезает вот в каком аспекте. Если у пользователя есть доступ к таблицам, ограниченный RLS, выполнение отчета не требует никаких специфических прав. Мне не совсем понятно почему Вы коррелируете суперпользователя с RLS?! Беру Вашу фразу и чуть меняю: Если у пользователя есть доступ к представлениям, в которых реализовано RLS, выполнение отчета не требует никаких специфических прав. Т.о. наличие этого пользователя совсем необязательно. То, что Oracle RLS встроено в ядро - это его заслуга. Но, Вы упорно хотите свести все к одному: pkarklin использует представления только потому, что работает с MS SQL, которые не имеет поддержки RLS на уровне ядра. Я писАл, что использую не только представления при отстутствии прямого доступа пользователя к таблицам. И основная цель это как раз облегчение работы пользователей которым совсем не обязательно знать, что физически сущность платежное поручение лежит в трех таблицах. softwarerТеперь, допустим, ваш суперпользователь сделал отчет в виде view или хранимки, грантовал этот объект нужным пользователям, точно так же положил на экселевский лист. Что происходит дальше... К чему пришли? К тому, что суперпользователь не является адекватной заменой RLS. Простите я где-то утверждал, что "суперпользователь является адекватной заменой RLS"?! Вы опять, почему-то, трактуете мои слова так, как Вам того хочется. Делая Выводы и оспраивая то, что я даже не произносил. softwarerХм. Судя по последнему ответу, Вы совершенно не поняли сказанного и отвечаете невесть на что. Ну, понеслось... Я все прекрасно понял... softwarerOracle Discoverer - это инструмент, позиционирующийся как средство для аналитиков, позволяющее не писать селекты. Попросту говоря, визуальный конструктор отчетов. Какая "необходимая квалификация" для этого необходима? Спасибо, я в курсе. softwarerДалее, по поводу "обоснования требований прямого доступа". Простите, но я заранее уверен, что беседовать с Вами на эту тему бесполезно, просто потому, что Вы давным-давно заняли неконструктивную позицию и вряд ли с нее сдвинетесь. Аналогия здесь примерно следующая: Вы привыкли пользоваться амбарным замком... Ну, как Вам будет угодно. Но аналогия с амбарным замком мало тянет на конструктивизм. softwarerОбъясняю еще раз, максимально доступно: я нигде не говорил, что следует отказаться от view там, где они удобны. Я утверждаю, что работа только через view не позволит оптимально решить все задачи. Гм... Можно подумать, что утверждал где-то обратное?! ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 14:21 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
pkarklinИзвините, я ничего не предлагал... Я всего лишь указал возможное решение предоставления доступа к физичесим таблицам бд, если система спроектирована без оного: И у меня такая же нормальная камера хранения. Я вижу здесь те же недостатки и ни в одной из моих систем, к которых у пользователя нет доступа к таблицам, нет такого кладовщика. Повторюсь, я ничего не предлагал. Вы опять додумываете в нужную Вам сторону. Павел, слова про "дать db_datareader" принадлежат именно Вам, никто Вас за язык не тянул и никто вместо Вас его не додумывал. Пока Вы не сказали, я не знал, что это такое, когда сказали - посмотрел в msdn и соответственно отвечал. Если теперь Вы говорите, что на самом деле этого не предлагали - ok, давайте отмотаем разговор назад и начнем с той же точки, где Вы ответили этим db_datareader-ом. pkarklinМне не совсем понятно почему Вы коррелируете суперпользователя с RLS?! Хм. Потому что он является Вашим ответом Чемберлену. Проследите скелет нашей дискуссии, там есть и примерно такая ветвь: я: RLS позволяет объединить безопасность и преимущества прямого доступа: вы: а можно сделать суперпользователя и обойтись без раздачи прямого доступа всем подряд То есть Вы противопоставили это решение решению с RLS. Соответственно, в этой ветви я доказываю, что такая замена неадекватна. pkarklinБеру Вашу фразу и чуть меняю: Если у пользователя есть доступ к представлениям, в которых реализовано RLS, выполнение отчета не требует никаких специфических прав. Т.о. наличие этого пользователя совсем необязательно. Абсолютно верная мысль, но она относится к другой ветке, про "что если пользоваться только вьюхами". См. http://softwarer.ru/about.html#Topic pkarklinТо, что Oracle RLS встроено в ядро - это его заслуга. Но, Вы упорно хотите свести все к одному: pkarklin использует представления только потому, что работает с MS SQL, которые не имеет поддержки RLS на уровне ядра. Думаю, Вы не сможете подтвердить свое утверждение цитатами. Что я "хочу свести" я уже сказал: по моим представлениям, Вы выработали свои принципы давно и применительно к конкретной обстановке, однако, судя по нашему предыдущему опыту, склонны абсолютизировать их. pkarklinЯ писАл, что использую не только представления при отстутствии прямого доступа пользователя к таблицам. И основная цель это как раз облегчение работы пользователей которым совсем не обязательно знать, что физически сущность платежное поручение лежит в трех таблицах. Павел, простите, но Вы писали довольно много того, что не укладывается в схему логического обсуждения основной темы. Я это не комментирую. pkarklinПростите я где-то утверждал, что "суперпользователь является адекватной заменой RLS"?! См. выше - мой ответ на "коррелируете". pkarklinНу, понеслось... Я все прекрасно понял... Поняли? Тогда Вас не затруднит ответить, какая именно квалификация в написании селектов необходима для пользования дискаверером (подчеркну - "необходима", а не "может пригодиться"). Но Вы почему-то предпочли прямо проигнорировать этот вопрос, что процитирую ниже. pkarklin softwarerКакая "необходимая квалификация" для этого необходима? Спасибо, я в курсе. Собственно цитирую. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 14:56 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
softwarerМожно. Правда, не знаю, зачем каждому бухгалтеру общий баланс банка, но готов принять как условный пример. Понятно, что условный. Бухгалтеру, контролирующему кредиты нужна сводная отчетность по кредитным договорам, ведущему депозиты - по депозитным. Смысл как раз в том, что вся эта сводная отчетность - полный аналог баланса (кстати баланс любого банка вообще говоря общедоступен) - не имея доступа к конкретным записям в таблицах получать некие аггрегированные величины. softwarerНо! Одно дело - контролируемое предоставление доступа к дополнительным полномочиям ("плюс общий баланс банка"), другое дело - тонкое место, которое будет регулярно рваться. В том то и дело, что для каждого вида сводной отчетности нужны свои дополнительные полномочия. То есть что при использовании RLS, что при ограничении доступа через вью потребуется создание специализированных методов доступа для каждого такого отчета. Bogdanov AndreyСкажу так: те два года, что я работал именно с аналитикой и аналитической отчетностью, постоянно вставала именно задача ограничения доступа ("... и чтоб ни чучелом, ни тушкой не увидел цифр по другому департаменту...") Забавно. Значит мы сталкивались с какой-то разной аналитикой. У меня как раз все-время были задачи - отчет должен строится по всему массиву данных, но вот конкретные договора соседнего отдела видеть - ни-ни. softwarer Bogdanov AndreyВ любом случае, человек, который разработывает отчеты (не знаю, почему его обозвали суперпользователем, если это обычный разработчик) Потому что pkarklin предложил дать этому разработчику привилегию SELECT ANY TABLE (точнее, ее mssql-ный аналог). А это уже никак не "обычный разработчик", если конечно "обычный разработчик" != "дба". Не знаю, что именно имел ввиду pkarklin, я же имею ввиду то, что разработчику доступна возможность изменять структуру СУБД (в части разработки новых вью и процедур и, естественно, эти вью создаются с использование прав "владельца схемы" - то есть практически дба). softwarer Bogdanov Andreyдолжен задуматься о том, каким образом должна сказываться система безопасности на данных, которые его отчет представляет. И никакая RLS здесь не поможет. Вы смотрите с точки зрения разработчика, а посмотрите еще и с точки зрения безопасника. RLS поможет в чем: в том, что для того, чтобы увидеть "недоступные в оперативной работе данные" придется прилагать специальные усилия. То есть действует принцип "запрещено все, что не разрешено". В то же время ее отсутствие приведет к тому, что каждый прямой доступ к объекту будет тонким местом в безопасности. Ну а использование только доступа через вьюхи, при адекватной безопасности будет плохо с точки зрения удобства-скорости. Я никогда и не предлагал давать прямой досутп. То есть тонкого места - нет. Я сравниваю два варианта - вью и RLS. С точки зрения проектировния Oracle-овая RLS (с другими не знаком) ничем от вью не отличается. И в том и в том случае для приложений доступны некоторые реляционные структуры (вью от таблиц приложение все равно не отличит), состав данных в которых меняется в зависимости от присоединившегося пользователя. Для специализированных (сводных) запросов и в том и в том случае потребуются специальные вью, которые работают в "обход" ограничений на просмотр строк. Насколько вью буду медленне, чем RLS - сказать не могу (RLS в реальной жизни попользовать не пришлось - а баловство в домашних условиях не в счет). И кстати, не знаю можно ли вьюшками "обойти" ограничения RLS. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 15:12 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
Bogdanov AndreyДолжен отметить, что именно такие ситуации постоянно встречаются - для аналитической отчетности почти всегда требуется аггрегаты по более широкому спектру данных, чем доступные для непосредственной работы. А вот для оперативной отчетности (когда надо "напечатать" один живущий в СУБД "объект") почти всегда достаточно тех самых стандартных вью, о которых говорит pkarklin. именно так. Скажу больше. Недавно у нас был относительно большой спор о правах доступа, суть которого состояла в следующем: кредитному эксперту при анализе необходима информация о кредитах связаных лиц анализируемого клиента. При этом возможна ситуация, что у него по правам нет к ним доступа. Было принято решение эту информацию ему предоставить невзирая на права. Подчеркну, что речь идет не об отчете. Условно говоря, при поиске кредитов формочка показывает один список, но из него можно перейти на другую формочку, где список уже другой. С точки зрения "безопасника" - это не дыра, а широко открытая дверь. С точки зрения бизнеса - все нормально. Они согласны, все риски понимают. Им так надо. Замечу еще, что окончательные решения принимают отнюдь не безопасники. Их мнение учитывают, но и только. ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 15:13 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
softwarerПавел, слова про "дать db_datareader" принадлежат именно Вам, никто Вас за язык не тянул и никто вместо Вас его не додумывал. Пока Вы не сказали, я не знал, что это такое, когда сказали - посмотрел в msdn и соответственно отвечал. Александр, Вы же сами всегда настаиваете на том, чтобы Ваш собеседник учитывал контекст сказанных слов. Открутим назад и вспомним, как развевалась наша беседа: pkarklinГм... Не должен пользователь иметь никакого доступа к таблицам. Он вообще не должен знать как устроена модель данных. Все взаимодействие идет через хп, вью, функции. Даже если в системе и не требуется поддержка row-level security. softwarer Угу. После чего начинаются вопросы "а вот начальство просит меня состряпать пару отчетов над данными купленной системы...." pkarklinя лишь констатировал факт, что закрыт доступ к таблицам (что скрывает модель данных), но существующие view позволяют таким продвинутым пользователям получать информацию, представленную из модели в "удобоваримом виде" в соответствии с имеющимися полномочиями. Например, сущность "Платежное поручение" "состоит" из 3х таблиц (эдакий вариант наследования): Объект->Документ->Платежное поручение. Пользователю доступно представление "Платежное поручение", которое джоинит эти три таблицы и дает полный комплект аттрибутов сущности. Это то, что касается выборки. А есть набор хп для добавления, изменения, удаления. softwarerСкажу так: за всю свою трудовую практику я не сталкивался с более-менее большой системой, к которой заказчик не приписывал бы дополнительных отчетов. При этом платить вендору за каждый новый отчет и пару месяцев ждать результата заказчика чаще всего не устраивает, поэтому в большинстве случаев отчеты приделываются собственными силами - либо штатными айтишниками, либо грамотными людьми из числа пользователей. pkarklinНе спорю, что такой человек (группа) существует в любой организации, использующей то или иное решение. И этот человек (группа) наделен определенными полномочиями в бд, например, имеет право читать из всех таблиц (например, в MS SQL достаточно включить его в роль бд db_datareader). Но это человек, умеющий это делать и понимающий свою ответственность. Но я не вижу из этого прямого следствия необходимости прямого доступа к таблицам остальных рядовых (читай неграмотных) пользователей. И после этого Вы в результат неких своих умозаключений делаете вывод: softwarerК чему пришли? К тому, что суперпользователь не является адекватной заменой RLS. pkarklinМне не совсем понятно почему Вы коррелируете суперпользователя с RLS?! softwarerХм. Потому что он является Вашим ответом Чемберлену. Проследите скелет нашей дискуссии, там есть и примерно такая ветвь: я: RLS позволяет объединить безопасность и преимущества прямого доступа: вы: а можно сделать суперпользователя и обойтись без раздачи прямого доступа всем подряд Обратите внимание, что Вы исходите из постулата, что основной целью, которую я приследую, закрывая доступ к таблицам бд - это поддержка RLS. С чего Вы это взяли, ума неприложу. Видимо у нас и на "скелет беседы" разные взгляды. М.б. тогда разделим и четко определим 2 темы: 1. Реализация RLS в конкртеной СУБД (на примере Oracle и MS SQL). 2. Цели, приемущества и недестатки от закрытия прямого доступа к таблицам. М.б. тогда "селет беседы" у нас будет более стройным. softwarerПавел, простите, но Вы писали довольно много того, что не укладывается в схему логического обсуждения основной темы. Я это не комментирую. Ок. Спрошу прямо. Что Вы считаете "основной темой", которую мы обсуждаем? авторТогда Вас не затруднит ответить, какая именно квалификация в написании селектов необходима для пользования дискаверером (подчеркну - "необходима", а не "может пригодиться"). В Вашем примере с дискаверером высокая квалификация не является необходимой, ибо описание метаданных или создается разработчиком или генериться по метаданным хранилища. Я опять же не вижу почему это должны быть именно таблицы, а не представления. Т.е. почему нужно иметь именно доступ к таблицам бд? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 15:34 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
Что касаемо варианта реализации RLS в MS SQL. Рассмотрим пример, когда определенным менеджерам надо давать права на работу только с определенными счетами. Скрипты объектов (без констрэйнтов): Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36. 37. 38. 39.
Заполняем данные, исходя из условий, что пользователи proba1 и proba2 существуют в бд. Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15.
Выдаем права: Код: plaintext
Заходим под proba1 и и пробуем: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34. 35. 36.
И под proba2: Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17. 18. 19. 20. 21. 22. 23. 24. 25. 26. 27. 28. 29. 30. 31. 32. 33. 34.
softwarerRLS поможет в чем: в том, что для того, чтобы увидеть "недоступные в оперативной работе данные" придется прилагать специальные усилия. То есть действует принцип "запрещено все, что не разрешено". В то же время ее отсутствие приведет к тому, что каждый прямой доступ к объекту будет тонким местом в безопасности. Ну а использование только доступа через вьюхи, при адекватной безопасности будет плохо с точки зрения удобства-скорости. Как повашему, в чем будет отличие в поведении вышеприведенного кода от реализации такого же функционала в Oracle? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 17:01 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
--т.е. даем 'Манагер1' "права" на счет с ID = 1, а 'Манагер2' и на 1 и на 1 читать как --т.е. даем 'Манагер1' "права" на счет с ID = 1, а 'Манагер2' и на 1 и на 2 ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 17:01 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
pkarklin--т.е. даем 'Манагер1' "права" на счет с ID = 1, а 'Манагер2' и на 1 и на 1 читать как --т.е. даем 'Манагер1' "права" на счет с ID = 1, а 'Манагер2' и на 1 и на 2 Дело в том, что данный метод действителен только для преопределенных прав (условие WHERE M.colUserName = USER_NAME() в вашем примере) Предположим, что Код: plaintext 1. 2. 3. 4. 5. 6. 7. 8. 9. 10. 11. 12. 13. 14. 15. 16. 17.
Как вы предлагаете в данном контексте работать? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 18:43 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
и уточните речь идёт о web-системах в том числе или только клиент-сервер? ... |
|||
:
Нравится:
Не нравится:
|
|||
20.02.2007, 18:52 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
KGPДело в том, что данный метод действителен только для преопределенных прав (условие WHERE M.colUserName = USER_NAME() в вашем примере) Любая реализация RLS исходит из предопределенных прав. Это может быть привязка к имени пользователя (как в моем примере), членства пользователя в группе (WHERE IS_MEMBER('SomeRole' = 1)) т.е. к неким "системным идентификаторам контекста". Такой подход применим в случае, когда каждый пользователь имперсонализирован в системе с помощью какого-либо "системного идентификатора контекста". Но, совсем не обязательно, чтобы идентификатор контекста был именно системным. Это может быть любой другой идентификатор, который бы определял контекст выполнения запроса. KGPПредположим, что ... Как вы предлагаете в данном контексте работать? В этом контексте - никак. Ибо в приведенном Вами примере нехватает основного - как идентифицировать контекст выполнения запроса. Т.е. к какому ManagerID принадлежит контекст текущего выполняемого запроса. KGPи уточните речь идёт о web-системах в том числе или только клиент-сервер? В не зависимости от типа системы для реализации RLS должно выполняться требование - наличие возможности идентифицировать контекст выполнения запроса. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2007, 08:45 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
Джентльмены и особенно Павел - прошу прощения, к сожалению, я уже почти сутки не могу выделить время для достаточно обстоятельного ответа. Как только смогу - отвечу, если конечно к тому моменту тема еще будет актуальной. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2007, 14:40 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
pkarklin В этом контексте - никак. Ибо в приведенном Вами примере нехватает основного - как идентифицировать контекст выполнения запроса. Т.е. к какому ManagerID принадлежит контекст текущего выполняемого запроса. Применение хранимок снимает данные ограничения, возможностью передачи контекста как параметра вызова Вопрос: Создать view с WITH CHECK OPTION можно с использованием, например ... getdate() Есть ли методы передачи некоего контекста при исполнении команды (например через временную переменную) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2007, 15:01 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
KGPСоздать view с WITH CHECK OPTION можно с использованием, например ... getdate() Вы имеете ввиду использование GETDATE() в WHERE? Это же не функция. Во вью нет таких ограничений. Вот только что в результате получиться? KGPЕсть ли методы передачи некоего контекста при исполнении команды (например через временную переменную) Можно использовать: SET CONTEXT_INFO Associates up to 128 bytes of binary information with the current session or connection. Syntax SET CONTEXT_INFO { binary | @binary_var } И затем при необходимости читать его: Код: plaintext 1. 2. 3. 4. 5.
... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2007, 15:18 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
KGPПрименение хранимок снимает данные ограничения, возможностью передачи контекста как параметра вызова только плохонькая безопасность получится. KGPЕсть ли методы передачи некоего контекста при исполнении команды (например через временную переменную) Это больше для ГФ вопрос. Почитайте про SET CONTEXT INFO, может это то, что вам нужно. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2007, 15:19 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
pkarklin 1. Вы имеете ввиду использование GETDATE() в WHERE? 2. Это же не функция. 3. SET CONTEXT_INFO 1. Не конкретно GETDATE , а нечто в принципе 2. Что не функция, где кто о чем говорил, что надо функция? 3. Верное направлени; binary - преобразование необходимо и join лишний к master..., надо попробовать на кошечках to Alexey Kudinov : 1. В чем плоханькая? передал тикет, по нему получил контекст для проверки 2. Что есть ГФ ? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2007, 15:42 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
KGPПрименение хранимок снимает данные ограничения, возможностью передачи контекста как параметра вызова А в чем тогда безопасность заключается? Этак любой товарищ вызовет процедурку передав на вход контекст другого пользователя. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2007, 15:46 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
Bogdanov Andrey KGPПрименение хранимок снимает данные ограничения, возможностью передачи контекста как параметра вызова А в чем тогда безопасность заключается? Этак любой товарищ вызовет процедурку передав на вход контекст другого пользователя. Под контестом я понимаю некие данные, а вы, вероятно, UserID ? можно использовать Ticket uniqueidentifier, создавая запись о сессии работы пользователя в АИС to pkarklin : зззжальтесь, что есть ГФ? ... сам форум MSSQL? ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2007, 15:55 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
KGPзззжальтесь, что есть ГФ? ... сам форум MSSQL? Я не знаю, откуда это пошло, но ГФ (Главным форумом) считается форум по MS SQL. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2007, 16:00 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
KGPПод контестом я понимаю некие данные, а вы, вероятно, UserID ? И что помешает злоумышленнику передать эти некие данные? Сложность их извлечения? Любая СУБД как раз и обеспечивает то, что при logon один раз передаются "некие данные" (называемые паролем), а потом уже ничего передавать не надо. А передавать такие данные каждый раз - серьезная брешь в безопасности. И напомню, что речь шла о двузвенной архитектуре. ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2007, 16:02 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
Bogdanov Andrey KGPПод контестом я понимаю некие данные, а вы, вероятно, UserID ? 1. И что помешает злоумышленнику передать эти некие данные? 2. Любая СУБД как раз и обеспечивает то, что при logon один раз передаются "некие данные" (называемые паролем), а потом уже ничего передавать не надо. 3. А передавать такие данные каждый раз - серьезная брешь в безопасности. 4. И напомню, что речь шла о двузвенной архитектуре. 1. Отсутствие знаний об этих данных 2. ничего - сказано имхо неверно, данные передаются КАЖДЫЙ раз по протоколу ниже уровнем 3. имхо - они и так передаются, только средствами операционки 4. уточнял, не факт. (дайте ссылку) ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2007, 16:24 |
|
БД MSSQL 2005 и IE
|
|||
---|---|---|---|
#18+
почитал, врубиться не смог, стыдно... но так люблю тонких клиентов, что не могу молчать. ASP.NET, application server & database server - это лучшее, что придумано в IT для автоматизации складов. Альтернатива - только терминальные решения. Но тонкий клиент через эксплорер все-таки лучше. Единственный недостаток - надо будет сократить несколько ставок в ай-ти сопровождении за ненадобностью. Правда, баркод-ридеры у нас все еще работают в традиционным клиентом - специфический экран ... |
|||
:
Нравится:
Не нравится:
|
|||
21.02.2007, 17:38 |
|
|
start [/forum/topic.php?fid=33&msg=34347308&tid=1549145]: |
0ms |
get settings: |
10ms |
get forum list: |
13ms |
check forum access: |
4ms |
check topic access: |
4ms |
track hit: |
126ms |
get topic data: |
11ms |
get forum data: |
3ms |
get page messages: |
62ms |
get tp. blocked users: |
1ms |
others: | 13ms |
total: | 247ms |
0 / 0 |