Алексей КМСУКак я понимаю, у Алексей К как-раз "архитектура" с супер-пользователем в строке соединения.Нет.
А какая у тебя архитектура? ;)

Алексей КМСУпропущено...

Человеческий фактор впринципе исключён? :)Если всё так строго - используйте аппаратный ключ + VPN - и тогда пофиг какая там архитектура.
Ты на вопрос так и не ответил ) Во-вторых, причем тут туннелирование, речь о соединении с БД.

Алексей КМСУпропущено...

Причем тут защита от sa? Я тебе говорю о том, что ни в коей мере нельзя использовать сиквельную аутентификацию с супер-пользователем в топологии "двухзвенка".Что такое супер-пользователь? sysadmin или db_owner ? Если так - то я этого не предлагал.
Супер пользователь БД в строке соединения приложения - это пользователь БД, который обладает достаточными правами для решения 100% задач твоего приложения (чтение, изменение, удаление и т.д.).

Алексей КМСУпропущено...

А какая у тебя архитектура? ;)В старых проектах или в новых? :-)
Начинается :) В обоих )

Алексей КПочему тогда "супер"? Просто пользователь БД, обладающий минимально необходимыми для работы правами.
Наоборот, пользователь БД, обладающий максимально необходимыми для работы правами. "Супер" - в контексте приложения.
То есть, разруливание ролевыми политиками идет у тебя самим приложением на основе табличек с юзерами и ролями. Но все запросы на сервере выполняются из-под супер пользователя. Очень популярная практика, но небезопасная в контексте подломить строку соединения через дизассемблер.

МСУпропущено...

Начинается :) В обоих )А какая разница? Мы сейчас конкретно обсуждаем классический 2-х звенный клиент-сервер.[/quot]
Ответь на мой вопрос, ок? :)

Алексей КМСУОтветь на мой вопрос, ок? :)Нет :-)
Почему?

Алексей Кзы: Я противник использования суперпользователей в двухзвенке.
А кули ты тогда насилуешь мой моцк?

Алексей КНет, значит "не использую суперпользователя в двухзвенке", а не "не хочу отвечать" :-)
Еще раз :)

Правильно ли я трактую твой ответ на свой вопрос? :)

Шапито на привалеМСУ: А какая у тебя архитектура? ;)
Алексей К: Не использую суперпользователя в двухзвенке.

Лёня, тут либо я талпаёп либо... Вообщем, объяснись!

Алексей КМСУВообщем, объяснись!
1. Суперпользователь в 2-х звенке - зло! Этот вариант даже не рассматривается.
2. Разглашение пароля НЕсуперпользователя тоже не сулит ничего хорошего, поэтому обсуждение имеет место быть.
3. Главное - не хранить пароль на диске. Пусть пароль вводится ( с клавиатуры, электронной карты или как-то иначе ) каждый раз, как минимум при запуске программы.
4. Пароль в оперативной памяти может хранится в открытом виде. Пользователь и так знает свой пароль, а студент с дизассемблером не пройдёт!
1. Ок.
2. Что это за пользователь? Речь о пользователе приложения (табличка Users, Active Directory) или это пользователь БД (сиквельный юзер)?
3. ...
4. Значит, ты меня так нихрена и не понял

Леша, еще раз, какая у тебя архитектура безопасности?

Давай сначала... Юзеры хранятся в табличке Users, так?

Алексей КМСУДавай сначала... Юзеры хранятся в табличке Users, так?Я говорю про архитектуру, в которой юзеры хранятся в системной sysusers . Т. е. в прикладных целях используется система безопасности СУБД. Как это ещё объяснить я уже не знаю.
Что мешало это сразу сказать, а не насиловать моск? ))
Кстати, вариант плохой.

AntonariyПо многим причинам. EF сам строки составляет, мне нужно лишь указать сервер и базу. Еще UDL не поддерживает net-провайдеров, которыми пользуется EF, тем более в его строках есть какие-то метаданные. Соответственно, скорее всего сам EF не поддерживает udl.
Ну вот, сам ответил на все вопросы. UDL не способен решать разносторонние задачи, присущие конфигу. Пережиток прошлого, не более того.

AntonariyЯ не точно выразился, json-приложение. В том смысле, что с сервера передаются лишь данные. Шаблоны транспорта не должны меняться, тем более часто.
Вот именно, если шаблоны не должны меняться, тогда подход xslt - как кобыле пятое колесо, бесспорно. Тем более xslt известен своими тормозами (его еще скомпилировать и выполнить нужно). Применение xslt подхода должно быть четко обосновано, если его лепят куда ни попадя, расстрелять :)

vahкак редактировать app.config и надо ли вообще?
Либо руками, либо предоставить пользователю UI, либо через ClickOnce обновлять, либо программно. В зависимости от потребности.

AntonariyМСУНу вот, сам ответил на все вопросы. UDL не способен решать разносторонние задачи, присущие конфигу. Пережиток прошлого, не более того.Тем не менее, для двухзвенок, не решающих разносторонние задачи, не использующих 100500 соединений, .net-провайдеров и прочие современные навороты — удобно :)
Если у тебя в качестве конфигурируемых параметров одна строка соединения, то можно. Но никто не гарантирует, что завтра не появится еще что-то, что нужно конфигурить. И тебе придется менять концепцию ведения настроек. А зачем себе изначально закладывать гранату под бок, если ситуацию можно решить стандартными нативными средствами?