Autenticación de Usuarios SQL7.0 desde PB60
Hola Antonio, mi consulta es la siguiente:
Tengo una aplicación en PB60 que se conecta por cliente nativo a SQL70 a través de un fichero INI que indica lo de siempre.
El Script de conexión de la aplicación se realiza a través de SQLCA.
Por otro lado, SQL70 posee dos modos de autenticación: 1.Windows+SQL y 2.Windows.
Por defecto viene determinado el modo 1.
Bien, mi idea es que el usuario tenga el misma usuario y contraseña del SO (Windows 2000 + AD). Si pruebo el aplicativo en el modo 1 añadiendo en SQL un usuario del SO, no funciona.
Sin embargo, en el modo 2 de SQL, si funciona; pero da igual la contraseña que pongas y eso no es bueno.
Por favor, necesito los consejos de un sabio.
Gracias de antemano.
Tengo una aplicación en PB60 que se conecta por cliente nativo a SQL70 a través de un fichero INI que indica lo de siempre.
El Script de conexión de la aplicación se realiza a través de SQLCA.
Por otro lado, SQL70 posee dos modos de autenticación: 1.Windows+SQL y 2.Windows.
Por defecto viene determinado el modo 1.
Bien, mi idea es que el usuario tenga el misma usuario y contraseña del SO (Windows 2000 + AD). Si pruebo el aplicativo en el modo 1 añadiendo en SQL un usuario del SO, no funciona.
Sin embargo, en el modo 2 de SQL, si funciona; pero da igual la contraseña que pongas y eso no es bueno.
Por favor, necesito los consejos de un sabio.
Gracias de antemano.
Respuesta de Antonio Garcia
1
Vamos por pasos.
Desde mi punto de vista personal, el utilizar la contraseña de windows o nt, igual a la de SQL-server, es un poco arriesgado, pues aumenta el numero de posibilidades de fallo, personalmente prefiero un control de contraseñas por separado.
Con respecto a el cambio de la contraseña, la idea es buena y personalmente yo la estoy utilizando, sin embargo si estas pensando en alinear o sincronizar la clave del terminal con la de sql-server, la verdad este procedimiento de cambio de clave por medio de tu aplicativo, no tiene sentido, simplemente haces una llamada a la ventana de cambio de clave propia de windows y asunto finalizado.
Por otro lado si mantienes la independencia de claves, estoy de acuerdo en añadir dicha opción.
Como te digo personalmente utilizo esta situación.
La idea.
He creado una ventana con los campos que tu igualmente propones,
El primero el password actual: este password es verificado en función del objeto de conexión, por ejemplo SQLCA, dentro de esta clase, encuentras una propiedad que contiene el password del usuario que hizo una conexión permitida en la base de datos de turno.
Entonces lo único que tienes que hacer es comparar el valor que ingresa en la casilla de CLAVE ACTUAL con el valor de SQLCA. LOGPASS
Los valores NUEVA CLAVE y CONFIRMACIÓN DE CLAVE, los evalúas localmente en la ventana de cambio de clave, estos evidentemente tienen que ser iguales para permitir al proceso final.
Si todo va bien, el cambio final lo hace como bien dices el procedimiento almacenado, sp_password,
este procedimiento simplemente recibe 2 argumentos,
old_password y new_password.
El script que yo utilizo es:
/* CAMBIO DE PASSWORD
Utiliza el objeto transacción SQLCA
Parametros:
as_oldPassword STRING Password Antiguo,
as_newPassword STRING Nuevo Password
*/
BOOLEAN lb_auto_commit
BOOLEAN lb_return
STRING ls_error
lb_auto_commit = SQLCA.AutoCommit
SQLCA.AutoCommit = TRUE // Para que permita ejecutar el sp_password
// Prepara y ejecuta el cambio de Password
DECLARE sp_password PROCEDURE FOR sp_password
@old = :ls_old_pass,
@new = :ls_new_pass
USING SQLCA;
EXECUTE sp_password;
ls_error = SQLCA.SQLErrText
IF (SQLCA.SQLCode = 100) THEN
MessageBox('ATENCION','Su password fue cambiado')
SQLCA.LogPass = ls_new_pass
lb_return = TRUE
ELSE
if (trim(ls_error) = '') then
ls_error = 'Los datos son incorrectos, la clave no fué cambiada'
end if
MessageBox('ERROR', ls_error)
lb_return = FALSE
END IF
SQLCA.AutoCommit = lb_auto_commit // Regresa al Default
RETURN(lb_return)
Esto lo puedes incluir en una función que como podrás observar devuelve un valor boolean.
En el script existe un inconveniente.
Observa el cambio en la propiedad SQLCA. AutoCommit, primero en true y luego lo restauro,
lo que sucede es que si la propiedad SQLCA. AutoCommit no es colocada en verdadero, el proceso de congela, y el cambio no se da.
Por cierto, esto que te estoy enviando me ha funcionando con las versiones sql-server 7 y 2000
Desde mi punto de vista personal, el utilizar la contraseña de windows o nt, igual a la de SQL-server, es un poco arriesgado, pues aumenta el numero de posibilidades de fallo, personalmente prefiero un control de contraseñas por separado.
Con respecto a el cambio de la contraseña, la idea es buena y personalmente yo la estoy utilizando, sin embargo si estas pensando en alinear o sincronizar la clave del terminal con la de sql-server, la verdad este procedimiento de cambio de clave por medio de tu aplicativo, no tiene sentido, simplemente haces una llamada a la ventana de cambio de clave propia de windows y asunto finalizado.
Por otro lado si mantienes la independencia de claves, estoy de acuerdo en añadir dicha opción.
Como te digo personalmente utilizo esta situación.
La idea.
He creado una ventana con los campos que tu igualmente propones,
El primero el password actual: este password es verificado en función del objeto de conexión, por ejemplo SQLCA, dentro de esta clase, encuentras una propiedad que contiene el password del usuario que hizo una conexión permitida en la base de datos de turno.
Entonces lo único que tienes que hacer es comparar el valor que ingresa en la casilla de CLAVE ACTUAL con el valor de SQLCA. LOGPASS
Los valores NUEVA CLAVE y CONFIRMACIÓN DE CLAVE, los evalúas localmente en la ventana de cambio de clave, estos evidentemente tienen que ser iguales para permitir al proceso final.
Si todo va bien, el cambio final lo hace como bien dices el procedimiento almacenado, sp_password,
este procedimiento simplemente recibe 2 argumentos,
old_password y new_password.
El script que yo utilizo es:
/* CAMBIO DE PASSWORD
Utiliza el objeto transacción SQLCA
Parametros:
as_oldPassword STRING Password Antiguo,
as_newPassword STRING Nuevo Password
*/
BOOLEAN lb_auto_commit
BOOLEAN lb_return
STRING ls_error
lb_auto_commit = SQLCA.AutoCommit
SQLCA.AutoCommit = TRUE // Para que permita ejecutar el sp_password
// Prepara y ejecuta el cambio de Password
DECLARE sp_password PROCEDURE FOR sp_password
@old = :ls_old_pass,
@new = :ls_new_pass
USING SQLCA;
EXECUTE sp_password;
ls_error = SQLCA.SQLErrText
IF (SQLCA.SQLCode = 100) THEN
MessageBox('ATENCION','Su password fue cambiado')
SQLCA.LogPass = ls_new_pass
lb_return = TRUE
ELSE
if (trim(ls_error) = '') then
ls_error = 'Los datos son incorrectos, la clave no fué cambiada'
end if
MessageBox('ERROR', ls_error)
lb_return = FALSE
END IF
SQLCA.AutoCommit = lb_auto_commit // Regresa al Default
RETURN(lb_return)
Esto lo puedes incluir en una función que como podrás observar devuelve un valor boolean.
En el script existe un inconveniente.
Observa el cambio en la propiedad SQLCA. AutoCommit, primero en true y luego lo restauro,
lo que sucede es que si la propiedad SQLCA. AutoCommit no es colocada en verdadero, el proceso de congela, y el cambio no se da.
Por cierto, esto que te estoy enviando me ha funcionando con las versiones sql-server 7 y 2000
