Cadena conexion a SQL Server.

"Tomas" wrote in message
news:

Tengo una duda sobre la conexión a una base de datos SQL Server cuando se
despliega una aplicación.
[...]
¿Crean un archivo INI o XML donde guardan los datos de conexión?

Típicamente se guarda en un archivo XML... pero no se crea un nuevo
archivo solo para eso, sino que se usan las clases que leen y graban el
archivo que tiene los "Settings" de la aplicación (que internamente es un
XML, pero no hace falta nunca abrirlo directamente).

Durante la instalación del programa, o bien al ejecutarlo por primera
vez, se abre una ventana en la que se preguntan los datos del servidor, y se
salva la cadena en los Settings. Lógicamente, tienen que ser los Settings de
Usuario, no los de Aplicación, ya que estos últimos normalmente son de
solo-lectura.

¿Si deben guardar un usuario y una contraseña, como se plantea la
seguridad para guardar los datos de la cadena de conexión?

Idealmente convendría usar siempre autenticación integrada, para no
tener que salvar usuario y contraseña, pero si no hay más remedio que salvar
esos datos, se salvan. El archivo de los Settings está protegido por los
permisos NTFS de forma que solo lo puede leer el propio usuario cuyos
ajustes se están salvando. Y ese usuario de todas formas conoce el usuario y
contraseña, ya que tiene que introducirlos la primera vez para que el
programa comience a funcionar. Así que no resulta un riesgo excesivamente
grande.

Gracias Alberto,

Durante la instalación del programa, o bien al ejecutarlo por primera
vez, se abre una ventana en la que se preguntan los datos del servidor, y
se salva la cadena en los Settings. Lógicamente, tienen que ser los
Settings de Usuario, no los de Aplicación, ya que estos últimos
normalmente son de solo-lectura.

¿Tienes un ejemplo o conoces un enlace para leer sobre los Settings de
Usuario para profundizar sobre el tema?

Idealmente convendría usar siempre autenticación integrada, para no
tener que salvar usuario y contraseña, ...

Con esta idea, entiendo que sería el administrador de la base de datos,
(cuando es una versión SQL empresarial), el encargado de dar de alta los
usuarios en la base de datos y asignar los permisos a cada uno según el
criterio de la empresa, ¿es esa la idea para una instalacion en un servidor?

Siguiendo con la misma idea, cuando la aplicación se instale en un PC con
una versión de SQL Express, (que no tiene las facilidades de administracion
de la versión empresarial), el usuario del PC sería de igual modo el
encargado de dar de alta los usuarios de ese PC que pueden acceder a la base
de datos. Estoy aplicando la idea de que no se debe trabajar en un PC, por
motivos de seguridad, con un usuario con provilegios de administrador, por
lo tanto, el usuario que instale la base de datos, no tiene porque ser el
que luego utilice la aplicación y por ende al no ser administrador, no tiene
permisos directos. ¿es así el enfoque para un PC?

Gracias por su tiempo.

"Tomas" wrote in message
news:%23zeDER%

Gracias Alberto,
¿Tienes un ejemplo o conoces un enlace para leer sobre los Settings de
Usuario para profundizar sobre el tema?

Empieza por esta página de MSDN:
http://msdn.microsoft.com/es-es/lib...6c3a0.aspx
y luego ve siguiendo los enlaces que hay al pie de la misma.

Idealmente convendría usar siempre autenticación integrada, para no
tener que salvar usuario y contraseña, ...

Con esta idea, entiendo que sería el administrador de la base de datos,
(cuando es una versión SQL empresarial), el encargado de dar de alta los
usuarios en la base de datos y asignar los permisos a cada uno según el
criterio de la empresa, ¿es esa la idea para una instalacion en un
servidor?

Eso es, en el servidor de base de datos se darían de alta los usuarios
de Windows. De hecho, esa es la configuración predeterminada de Sql Server
cuando lo instalas. Para poder usar la autenticación en modo mixto (con
usuario y password), hay que activarla expresamente.

Usualmente lo mejor es dar de alta no un usuario, sino un grupo de
Windows al que se le dan permisos en Sql Server, y luego los usuarios que
tengan que tener esos permisos se van añadiendo al grupo.

Siguiendo con la misma idea, cuando la aplicación se instale en un PC con
una versión de SQL Express, (que no tiene las facilidades de
administracion de la versión empresarial), el usuario del PC sería de
igual modo el encargado de dar de alta los usuarios de ese PC que pueden
acceder a la base de datos. Estoy aplicando la idea de que no se debe
trabajar en un PC, por motivos de seguridad, con un usuario con
provilegios de administrador, por lo tanto, el usuario que instale la base
de datos, no tiene porque ser el que luego utilice la aplicación y por
ende al no ser administrador, no tiene permisos directos. ¿es así el
enfoque para un PC?

Con SQL Express, aparte de hacer lo que mencionas, hay una alternativa:
Si la base de datos es solo para ese usuario, entonces puedes montarla en
modo "User Instance" (poniendo lo de "attach..." en la cadena de conexión).
En este caso, el usuario que abre de esta manera el ".mdf" se convierte
automáticamente en dbo de esa base de datos, sin dar ningún permiso en Sql
Server (la seguridad en cuanto a "quién puede hacer esto" vendría dada por
los permisos NTFS del fichero .mdf).

Gracias Alberto, voy a leer este enlace que me comentas.

Saludos.

Estoy haciendo pruebas con el archivo de configuración app.config y no
termina de funcionar de la forma como yo lo necesito, porque necesito poder
modificar el archivo en tiempo de ejecucion.

Sólo funciona cuando se utiliza en una máquina con XP y trabajando como
Administrador. Si se trabaja con un usuario con acceso limitado (como es lo
normal) ya no funciona.

En los sistemas con Vista y Seven ya no funciona, incluso trabajando como
Administrador.

Cuando no funciona, el mensaje que aparece en todos los sistemas es el
siguiente:

"Se ha producido un error al cargar el archivo de configuración. Acceso
denegado a la ruta de acceso 'C:\Archivos de programa\Pruebas\hlsr7tl.tmp'.
(C:\Archivos de programa\Pruebas\Pruebas.config)"

Es una cuestion de permisos, normalmente, salvo que seas Administrador, en
la rama "C:\Archivos de programa", las aplicaciones no pueden escribir, por
esto me resulta extraño que Microsoft no tenga previsto esta restrición y
permita al usuario elegir el lugar donde abrir el archivo por motivos de
permisos.

¿Conoce alguien si hay alguna forma de poder mantener un archivo de
configuración en la carpeta que yo eliga, aprovechando las clases de
Microsoft para ahorrar trabajo y no tener que volver a inventar la rueda?

Gracias.
Tomás.