Здравствуйте, Gollum, Вы писали:
G>... и самый большой плюс — не нужно ставить MSDE в mixed security mode.
а в чем конкретно + ?
ок. подведу итог: если проект небольшой, не требует сложного сопровождения другими людьми (не девелоперами проекта), не нужно разделение прав для разных групп пользователей, железяка на которой все работает не имеет шансов когда-либо измениться — мы за пользователя ASPNET в MSDE.
Во всех же более сложных случаях говорить о преимуществах того либо друго подхода можно только исходя из конкретных бизнесс нужд.
Доброе время суток. Установил FRAMEWORK.NET и урезанный MSSQL в редакции MSDE. Пишу на C#. Накрапал простенькую прогу и скомпилил (консольным csc.exe)
Перебрал кучу вариантов ConnectionString но не могу подключиться к БД. Пробовал класс OleDbConnection и SqlConnection — одна и таже петрушка
Установил VS.NET и попробовал в окне дизайнера через Server Explorer — все подключается. Копирую оттуда строку соединения к себе в прогу — ни гугу
Вот строка соединения:
Provider=SQLOLEDB.1;Integrated Security=SSPI;Persist Security Info=False;Initial Catalog=master;Data Source=igor;Use Procedure for Prepare=1;Auto Translate=True;Packet Size=4096;Workstation ID=IGOR;Use Encryption for Data=False;Tag with column collation when possible=False
Вот какой получаю эксепшн: Login failed for user 'IGOR\ASPNET'
Юзер АСПНЕТ на машине присутствует как-бы незримо — залогиниться под ним нельзя, под ним крутится вроде как сам процесс среды аспнет.
Вместо Integrated Security=SSPI пробовал разные User ID=sa — говорит, что пользователя нет в списке для Trusted Sql Server. Где энтот список?
Что делать? Что проверять? Где ошибка?
Может это MSDE настолько кривой (при установке, кстати, не захотел ставиться без ключа SAPWD="AStrongSAPwd" — может в этом грабли?)
ВиндаХРпрофешнл.
Здравствуйте, Yachtsman, Вы писали:
Y>Здравствуйте, Ponch, Вы писали: P>>Вот какой получаю эксепшн: Login failed for user 'IGOR\ASPNET'
Y>А добавить этого пользователя в БД не пробовали?
Как добавить? Какие утилиты из пакета MSDE юзать?
ПС. У меня неполный MSSQL а обрезок MSDE.
Здравствуйте, Ponch, Вы писали:
P>Как добавить? Какие утилиты из пакета MSDE юзать? P>ПС. У меня неполный MSSQL а обрезок MSDE.
MSDE это не обрезок, а вполне функциональная вещь (к тому же бесплатная). Добавить можно либо через osql.exe и командную строку, либо поставить клиентские утилиты от Sql Server — и добавить пользователя через Enterprise Manager. Второе явно проще.
SqlConnection sc = new SqlConnection("Server=localhost;Database=myDB;Integrated Security=SSPI;Persist Security Info=False;")
Такой подход является не очень хорошим. Соединение будет использовать интегрированную виндовз секурити: если ASP работтает под пользователем ASPNET его придется сооздавать в скл сервере, что криво; если под имперсонизированным пользователем — еще хуже так как для каждого пользователя будет создан свой пул коннектов, что также не есть хорошо — коннектов то всего 5
Имхо лучшее решение — создать для каждой группы пользователей пользователя в базе.
Спасибо за ссылки а также всем ответившим.
Проблема решилась след. образом: действительно соединение с базой под под ISS и ASP.NET происходит под виртуальным юзером '<имя ПК>\APSNET'. Его я прописал в базах MSDE посредством скрипта sp_grantlogin и др. скриптов, дающих доступ к БД (долго ковырялся в MSDN и в инете, тк никакой литературы нет вообще — лень ехать на книжный рынок . Зато от души наигрался в запуски хранимых процедур sp_*, т.к. визуальных средств в MSDE нет вообще
Попутно еще поковырялся на предмет ключа ЛогинМоде для MSDE в реестре Винды. Выставил комбинированный логин не только с учетных записей винды, но и с юзеров, прописанных в базах MSDE. Все чудненько работает как под трастед_конекшнз так и под прописанным в БД юзером. Но появилось кучу других сумбурных вопросов — но в виде стройных мыслей еще не созрели
Еще раз спасибо.
Здравствуйте, ZevS, Вы писали:
G>>Чем это прямее чем добавить пользователя аспнет в sql? Разумеется речь идет о случаях, когда это возможно сделать.
ZS>Ну возьмем простейшую ситуацию — возникнет необходимость перенести базу на выделенный сервер БД. Ваши предложения по этому поводу?
Я как мне казалось явно написал что этот случай не рассматривается.
Здравствуйте, Gollum, Вы писали:
G>Я как мне казалось явно написал что этот случай не рассматривается.
Что-то я не заметил где это написано....
Я же про тот случай когда в данный момент и IIS и MSDE стоят на одной машине и сделать так вроде можно. Однако это не очень правильно (или даже очень неправильно) с точки зрения дальнейшей эксплуатации.
Приведу аналогию:
Одними из основных причин возникновения новых методологий программирования (структурное программирование -> ООП -> АОП -> ...) были как раз сопровождаемость + гибкость.
Вы же не будете пропив использования ООП если все можно закодировать более быстро одной функцией main и с использованием оператора goto?
Здравствуйте, ZevS, Вы писали:
ZS>Что-то я не заметил где это написано....
Видимо я не смог донести что подразумевалась именно такая ситуация.
ZS>Я же про тот случай когда в данный момент и IIS и MSDE стоят на одной машине и сделать так вроде можно. Однако это не очень правильно (или даже очень неправильно) с точки зрения дальнейшей эксплуатации.
MSDE он на то и MSDЕ Сразу видно что проект мелкий. Зачем мне изобретать нового пользователя? Зачем шифровать логин и пароль в конфиг файле или пихать его в реджистри для пущей надежности? Когда можно сделать все быстро и просто.
ZS>Приведу аналогию:
Я не согласен с этой аналогией Изменить строку соединения в web.config — дело минуты, никакого рефакторинга производить не нужно. Никакой особой кривизны в этом подходе нет.
Здравствуйте, 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% случаев. Хорошо, еще какие-нибудь аргументы есть?
Дорогие ученые! У меня в подполе который год раздается подземный стук. Объясните пожалуйста, как он происходит?
Здравствуйте, 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 для написания блокнота — если и не криво, то берд.
Re[14]: ASP.NET + MSDE. Не могу подключиться к БД
От:
Аноним
Дата:
02.12.04 13:50
Оценка:
можно спросить? а зачем вообще тогда в базе есть возможность назначать права, если это можно сделать на бизнес-уровне?
Затем, что базу придумали умные дяди задолго до того, как другие умные дяди придумали asp.net да и доступ к базе ограничивается не только конкретно твоим приложением, есть ещё администраторы, пользователи, и, по необходимости, куча других ролей.
Здравствуйте, Gollum, Вы писали:
G>Кстати за перестановку OS — хороший аргумент... Надо обдумать.
тут то как раз вроде все нормально....хотя....
А вот если разработка велась на одной машине, а работать все должно на другой (наиболее часто встречающаяся ситуация) — сможем ли мы просто восстановить backup базы на продакшне? будет ли ASPNET на новой мошине темже усером в MSDE? меня терзают смутные сомненья....
ASP.NET + MSDE. Не могу подключиться к БД
От:
Аноним
Дата:
07.12.04 15:58
Оценка:
Привет у меня была такая же проблема.В проекте открыл 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'.
. Зато от души наигрался в запуски хранимых процедур sp_*, т.к. визуальных средств в MSDE нет вообще 
— не там боятся надо. Давайте не рассматривать случаи когда админы — козлы или лохи, это задача не девелопера.