Здравствуйте, Gollum, Вы писали:
ZS>>Я же про тот случай когда в данный момент и IIS и MSDE стоят на одной машине и сделать так вроде можно. Однако это не очень правильно (или даже очень неправильно) с точки зрения дальнейшей эксплуатации.
G>MSDE он на то и MSDЕ Сразу видно что проект мелкий.
не факт, хотя ASP.NET + MSDE подталкивают к такому выводу...
G>Я не согласен с этой аналогией Изменить строку соединения в web.config — дело минуты, никакого рефакторинга производить не нужно. Никакой особой кривизны в этом подходе нет.
нужно будет как минимум заново прописывать права в базе.
Здравствуйте, ZevS, Вы писали:
ZS>не факт, хотя ASP.NET + MSDE подталкивают к такому выводу...
ASP.Net тут не при чем На асп.нет есть очень крупные проекты, и более того он и предназначен как раз для них А вот MSDE — тут все однозначно.
ZS>нужно будет как минимум заново прописывать права в базе.
А как максимум? В общем, кроме переноса базы на другую машину другие возражения есть?
Здравствуйте, Gollum, Вы писали:
G>ASP.Net тут не при чем На асп.нет есть очень крупные проекты, и более того он и предназначен как раз для них А вот MSDE — тут все однозначно.
про асп я сказал имее ввду что это очевдино сайт (интер или интра роли не играет).
ZS>>нужно будет как минимум заново прописывать права в базе.
G>А как максимум? В общем, кроме переноса базы на другую машину другие возражения есть?
а они нужны?
Кроме того что добавить пользователя аспнет проще другие доводы есть?
G>>А как максимум? В общем, кроме переноса базы на другую машину другие возражения есть?
хотя можно и привести
Вполне возможно что потребуется различные интерфейсы: для посетителей и для управления сайтом. Логично разделить security context для этих двух групп пользователей и наиболее приемлемое здесь решение — для пользователя в субд с разными правами.
Да. Я не к тому что моя точка зрения правильная или неправильная. Для вас может быть поменять строчку соединения чревато какими-то проблемами, я не знаю какими именно. Я вас переубедить не хочу, я хочу сформировать свое мнение. Какие еще грабли в данном случае? Я их не вижу, может их знаете вы, я скажу большое спасибо и поставлю соответствующую оценку. Так есть еще минусы кроме этого?
ZS>Кроме того что добавить пользователя аспнет проще другие доводы есть?
Читайте внимательней, я уже писал. Не нужно хранить user credentials в web.config или еще где-то, и самый большой плюс — не нужно ставить MSDE в mixed security mode.
Скорость перебора паролей прямо пропорциональна квадрату температуры утюга...
Здравствуйте, ZevS, Вы писали:
ZS>хотя можно и привести
Попробуйте
ZS>Вполне возможно что потребуется различные интерфейсы: для посетителей и для управления сайтом. Логично разделить security context для этих двух групп пользователей и
Ага и получить проблемы с коннекшн пулингом (о которых сами же и писали). Нет, у нас вариант когда все работает от одного пользователя.
ZS>наиболее приемлемое здесь решение — для пользователя в субд с разными правами.
Это не так Наиболее приемлимое решение — встроенная Forms аутентификация на основе ролей.
Здравствуйте, ZevS, Вы писали:
ZS>сорри, конечно же — два пользователя в субд с разными правами.
А ну в таком варианте пулинг не критичен. А смысл? Все равно надо будет настраивать Forms и роли. Двух пользователей не нужно в 90% случаев. Хорошо, еще какие-нибудь аргументы есть?
Дорогие ученые! У меня в подполе который год раздается подземный стук. Объясните пожалуйста, как он происходит?
Здравствуйте, Gollum, Вы писали:
G>... и самый большой плюс — не нужно ставить MSDE в mixed security mode.
а в чем конкретно + ?
ок. подведу итог: если проект небольшой, не требует сложного сопровождения другими людьми (не девелоперами проекта), не нужно разделение прав для разных групп пользователей, железяка на которой все работает не имеет шансов когда-либо измениться — мы за пользователя ASPNET в MSDE.
Во всех же более сложных случаях говорить о преимуществах того либо друго подхода можно только исходя из конкретных бизнесс нужд.
Здравствуйте, ZevS, Вы писали:
ZS>а в чем конкретно + ?
Не нужно бояться что кто-то sql поломает узнав пароль sa
ZS>ок. подведу итог: если проект небольшой, не требует сложного сопровождения другими людьми (не девелоперами проекта), не нужно разделение прав для разных групп пользователей, железяка на которой все работает не имеет шансов когда-либо измениться — мы за пользователя ASPNET в MSDE.
ZS>Во всех же более сложных случаях говорить о преимуществах того либо друго подхода можно только исходя из конкретных бизнесс нужд.
Согласен на 90% (не пойму причем тут сопровождение недевелоперами — все кто перемещает базы как правило смогут поменять строку соединения. Ну и подход с разными пользователями в базе мне никогда не нравился).
Но уж кривым я ни тот ни другой способ не назвал бы. Вот собственно к чему я это все.
Декадентство — это лежать на пляже у Великого Блинского болота и смотреть телевизор. В смокингах.
Здравствуйте, Gollum, Вы писали:
ZS>>Вполне возможно что потребуется различные интерфейсы: для посетителей и для управления сайтом. Логично разделить security context для этих двух групп пользователей и G>Ага и получить проблемы с коннекшн пулингом (о которых сами же и писали). Нет, у нас вариант когда все работает от одного пользователя.
ну да будет два пула — это не так страшно..
ZS>>наиболее приемлемое здесь решение — для пользователя в субд с разными правами. G>Это не так Наиболее приемлимое решение — встроенная Forms аутентификация на основе ролей.
можно спросить? а зачем вообще тогда в базе есть возможность назначать права, если это можно сделать на бизнес-уровне?
Здравствуйте, ZevS, Вы писали:
ZS>можно спросить? а зачем вообще тогда в базе есть возможность назначать права, если это можно сделать на бизнес-уровне?
Ну можно отдельный топик создать, если хочется Там отвечу да и народ сможет мнение высказать.
Дорогие ученые! У меня в подполе который год раздается подземный стук. Объясните пожалуйста, как он происходит?
Здравствуйте, ZevS, Вы писали:
ZS>ок. подведу итог: если проект небольшой, не требует сложного сопровождения другими людьми (не девелоперами проекта), не нужно разделение прав для разных групп пользователей, железяка на которой все работает не имеет шансов когда-либо измениться — мы за пользователя ASPNET в MSDE.
Кстати за перестановку OS — хороший аргумент... Надо обдумать.
Моя смерть ездит в черной машине с голубым огоньком
Здравствуйте, Gollum, Вы писали:
G>Не нужно бояться что кто-то sql поломает узнав пароль sa
во многих учреждениях тетечки записывают логин и пароль на листик и приклеивают его на монитор. — не там боятся надо. Давайте не рассматривать случаи когда админы — козлы или лохи, это задача не девелопера.
ZS>>Во всех же более сложных случаях говорить о преимуществах того либо друго подхода можно только исходя из конкретных бизнесс нужд. G>Согласен на 90% (не пойму причем тут сопровождение недевелоперами — все кто перемещает базы как правило смогут поменять строку соединения.
не не перепрописать права в базе
G>Ну и подход с разными пользователями в базе мне никогда не нравился).
просто вы их готовить не умеете — шутка.
G>Но уж кривым я ни тот ни другой способ не назвал бы. Вот собственно к чему я это все.
все опять таки зависит от конкретных нужд. использовать RUP для написания блокнота — если и не криво, то берд.
Здравствуйте, Gollum, Вы писали:
G>Кстати за перестановку OS — хороший аргумент... Надо обдумать.
тут то как раз вроде все нормально....хотя....
А вот если разработка велась на одной машине, а работать все должно на другой (наиболее часто встречающаяся ситуация) — сможем ли мы просто восстановить backup базы на продакшне? будет ли ASPNET на новой мошине темже усером в MSDE? меня терзают смутные сомненья....
Re[14]: ASP.NET + MSDE. Не могу подключиться к БД
От:
Аноним
Дата:
02.12.04 13:50
Оценка:
можно спросить? а зачем вообще тогда в базе есть возможность назначать права, если это можно сделать на бизнес-уровне?
Затем, что базу придумали умные дяди задолго до того, как другие умные дяди придумали asp.net да и доступ к базе ограничивается не только конкретно твоим приложением, есть ещё администраторы, пользователи, и, по необходимости, куча других ролей.
Привет у меня была такая же проблема.В проекте открыл Web.config после
<authentication mode="Windows" />
добавил
<identity impersonate="true" userName="domain\username" password="password"/>
все получилось без добавления user-a ASPNET
Здравствуйте, Аноним, Вы писали:
А>Здравствуйте, Аноним, Вы писали:
А>>http://www.gotdotnet.ru/Forums/DataWorks/26995.aspx
А>>данное сообщение получено с www.gotdotnet.ru А>>ссылка на оригинальное сообщение
А>Спасибо за ссылки а также всем ответившим. А>Проблема решилась след. образом: действительно соединение с базой под под ISS и ASP.NET происходит под виртуальным юзером '<имя ПК>\APSNET'. Его я прописал в базах MSDE посредством скрипта sp_grantlogin и др. скриптов, дающих доступ к БД (долго ковырялся в MSDN и в инете, тк никакой литературы нет вообще — лень ехать на книжный рынок . Зато от души наигрался в запуски хранимых процедур sp_*, т.к. визуальных средств в MSDE нет вообще А>Попутно еще поковырялся на предмет ключа ЛогинМоде для MSDE в реестре Винды. Выставил комбинированный логин не только с учетных записей винды, но и с юзеров, прописанных в базах MSDE. Все чудненько работает как под трастед_конекшнз так и под прописанным в БД юзером. Но появилось кучу других сумбурных вопросов — но в виде стройных мыслей еще не созрели А>Еще раз спасибо.
А вот у меня не все так гладко
sp_grantlogin и sp_grantdbaccess для ASPNET я вызвал, и к БД подключение проходит, а вот при попытке выполнить запрос SELECT такое исключение: SELECT permission denied on object 'Users', database 'TokaChatDB', schema 'dbo'.
Сразу видно что проект мелкий. 
— не там боятся надо. Давайте не рассматривать случаи когда админы — козлы или лохи, это задача не девелопера.
— шутка.
