Строки подключения к базе данных только для чтения

Question

Это кажется очень глупым вопросом, но я обыскал его и ничего не могу найти по этому поводу.

У меня есть строка подключения к БД, которую я создаю в своем файле web.config: -

<connectionStrings>   
<add name="DBConn" connectionString="Data Source=<db svr>;Initial Catalog=<dbname>;Integrated Security=True" providerName="System.Data.SqlClient />   
</connectionStrings>

или

Data Source=<db svr>;Database=<db name>;User ID=<uname>;Password=<pword>;

но мне нужно, чтобы это соединение было только для чтения. Я определил все мои объекты linq только для своих свойств, и ни один из моих классов репозитория (MVC) не содержит методов .SubmitChanges (), поэтому я на 99% уверен, что система не может обновить эту БД, но я также хотел бы установить соединение с БД на RO, если это вообще возможно. Я понимаю, что в идеале это должно быть сделано на стороне сервера SQL, и пользователь должен сделать RO, но это (по разным причинам, вне моего контроля) не может быть сделано, поэтому я хотел заблокировать соединение как приложение не должен писать в БД.

Есть ли параметр «только для чтения», который я могу применить к строке подключения, чтобы он выдавал ошибку или отбрасывал данные, если были предприняты какие-либо обновления?

Просто чтобы повторить (1-й ответ, который я получил, задавая этот вопрос на другом форуме, был «изменить учетные данные вашей БД»). Я никак не могу изменить учетные данные для доступа к БД, это RW и любая попытка изменить их (в настоящее время) аварийно завершает работу базы данных SQL-сервера. Это не моя проблема, и я не могу смотреть на решение этой проблемы, поэтому я хочу взглянуть на создание подключения к БД RO, так как это абсолютно, положительно должно убить каждого .... ошибаться, я имею в виду абсолютно, положительно невозможно изменить данные БД.

Приветствия

MH

Answer 1

Нет, нет пути (о котором я знаю). К сожалению, для вас правильным способом было бы изменить права текущего пользователя или создать нового пользователя только с избранными привилегиями. Я понимаю, что это не тот ответ, который вы ищете, но наличие сервера Sql, который дает сбой при попытке что-то изменить, кажется проблемой, которую действительно стоит рассмотреть. Это потому, что вы используете для подключения учетную запись "sa"? Если это так, вы должны создать другого пользователя и предоставить соответствующие разрешения новому пользователю.

Answer 2

То, что у вас есть под контролем - это классы доступа к коду (L2S). Я предлагаю переопределить в частичном классе SubmitChanges для вашего текста данных, чтобы ничего не делать (или даже выдать ошибку!) (Или реализовать все методы расширяемости InsertObject, UpdateObject или DeleteObject, которые принадлежат вашему текстовому тексту)

Answer 3

Это действительно зависит от того, какую базу данных и поставщика БД вы используете. Некоторые разрешают доступ только для чтения к строке подключения, другие - нет.

Например:

SQL Server 2005 CE при использовании поставщика данных .NET Compact Framework для SQL Server Mobile имеет возможный параметр File Mode=Read Only;. (см. connectionstrings.com ).

SQL Server 2008, не .

Вы можете проверить больше на connectionstrings.com .

Answer 4

на уровне строки подключения вы ничего не можете сделать, кроме записи пользователя, кроме изменения пользователя - что вы уже сказали, что не можете сделать.

В этом случае вам просто нужно сделать все возможное, чтобы предотвратить любые записи; то есть:

• любые открытые слои не должны предоставлять семантику обновления / удаления / вставки или что-либо еще.
• делает все классы слоя данных запечатанными, чтобы их нельзя было переопределить

Тем не менее, ничто не мешает программисту приходить, вырывать строку подключения и вставлять ее в свое собственное соединение для выполнения записи.

Таким образом, вы можете переместить строку подключения в другое место, к которому только внутренний код знает, как получить к нему доступ (хотя она все еще будет управляться текстовым файлом, но не используйте константу кода!); это все еще никому не мешает его использовать - но это делает его намного сложнее.

(добавлено) Я должен объяснить, почему это не защищает его.

Если оставить в стороне, что источник самой строки подключения, вероятно, будет доступен, даже благодаря защите с помощью библиотек шифрования и т. Д., Ничто не мешает мне размышлять над вашим кодом и вызывать его, кроме уровней доверия. Возможно, вы решите пройти весь путь запутывания, чтобы я не смог разобрать ваш код; но наверняка этот уровень паранойи не требуется в вашем доме разработки?

В конечном счете, тем не менее, потому что это «SEP» (чья-то проблема), как вы выразились, и вы не можете это контролировать - если кто-то спросит вас, почему, несмотря на все ваши усилия, вы не можете гарантировать что никакие записи не будут выполняться, вы можете смело обвинять «кого-то еще».