Depurador y CurrentPrincipal

16/01/2006 - 19:27 por AOG | Informe spam
hola, tengo un par de dudas

1º duda:
tego una solucion en VB 2005 final, formado por 4 proyecto 1º es la capa de
IU (Interfaz de Usuario), 2º un SW (Servico Web), 3º es la capa de negoacio y
4º Acceso a datos.
la solucion está en modo Debug, y pregunto por qué, y son muy poca veces, me
funciona ir depurando (interpretando)las líneas de código pasa por paso (F8)
empezando por el proyecto IU y me pasa al proyecto SW y sigue interpretando
linea por linea para ver el
conportamiento en la capa de negocio, y en la mayoria de veces
no me deja depurar, es decir se queda en el proyecto IU y no sigue
interpretando las
lineas de los demas proyectos, continuando en la siguiente linea del
poryecto IU, una vez
terminado la llamada al método del servico Web, vamos que no interpreta
paso a paso por lo demás proyecto. ¿Tengo algo mal configurado en mi VS?

2º duda
Otra cuestion es si desde la capa IU se hace una llamada un metodo del SW
el Thread.CurrentPrincipal es el mimo o conserva los mismos valores en todas
las llamadas,
hasque que se cambie en ese hilo de ejecusion. Lo digo por la seguridad ya
que tengo hecho
que en cada llamada de un metodo del SW la primera línea es recoger el
usuario y contraseña
de la cabecera SOAP y llamar a una funcion que si ha cambiado el
Thread.CurrentPrincipal.Identity.Name vuelvo
a buscar el usuario en la base de datos y comparar el que se pasa por la
cabecera
y permitirá o denegará continuar ejecutando el metodo si el usuario es
válido, si es
valido asigno el usuairo de la cabecera SAOP al
Thread.CurrentPrincipal.Identity
y en el caso que Thread.CurrentPrincipal.Identity.Name
es igual a la de la cabecera no busco en la BBDD y me ahorro acceder a la
BBDD.

Public Function ValidarUsuario(UsuarioActivo_CabSOAP,ClaveActivo_CabSOAP) as
Booleand
if Thread.CurrentPrincipal.Identity.Name <> UsuarioActivo_CabSOAP Then
dsUsu = BuscarUsuarioEnBBDD(UsuarioActivo_CabSOAP)
if dsUsu.Rows(0).Codigo = UsuarioActivo_CabSOAP and dsUsu.Rows(0).Clave =
ClaveActivo_CabSOAP then
AsignarNuevoUsuairoCurrentPrincipal(UsuarioActivo_CabSOAP)
return = true
else
return = false
end if
Else
return true
End if
End Function
¡Claro!, esto me sirve si conserva Thread.CurrentPrincipal.Identity.Name en
todas las llamadas
, en el caso que no, siempre estaría buscando en la BBDD, lo cual el
rendimiento será peor.
Si se accede directamente desde la IU a la capa de negocio si es el mismo
Hilo, pero cuando
hay un SW por medio, ignoro el comportamiento.

Lo que se trata de guardar el usuario activo en el SW para compara con el
que se pasa en
la cabecera SOAP cuando se llama a un metodo del dicho SW.
Si alguien me puede aportar una sugerencia mejor sobre este tema de
seguridad, se lo agradecería mucho.

Por favor, me gustaria que me despejarais estas dos dudas, un saludo.
 

Leer las respuestas

#1 CESAR DE LA TORRE [MVP]
17/01/2006 - 12:02 | Informe spam
Eso es normal, porque hay diferentes procesos 'en juego'. El proceso de tu
App.Cliente y el proceso del Servidor Web que es el que tiene en su espacio
de memoria las clases y métodos del WebService y de los objetos de negocio
y acceso a datos. Si haces un debugging normal (play), entras en Debuggin del
primere proceso. Para hacer Debugging del WebService o de los objetos de
negocio, tienes que hacer un "ATTACH TO PROCESS" al proceso del Servidor Web
que utilices. Se hace desde Visual Studio 2005, en :
Debug-->Attach to Process. Y ¿A que proceso concretamente?, pues depende del
Servidor Web que utilices:
1.- Mini-Servidor Web integrado en VS.2005 (llamado Cassini) --> proceso
"WebDev.WebServer.EXE"
2.- Servidor Web IIS de Windows XP, en el proceso del pool de WebSites por
defecto: --> proceso "aspnet_wp.exe"
3.- Servidor Web IIS de Windows Server 2003, en el proceso del pool de
WebSites por defecto: --> proceso "w3wp.exe".
Y VS.2005 queda 'esperando' en modo DEBUGGING.
Después arranca la aplicación cliente SIN DEBUGGING, haciendo doble clic
directamente en el .EXE, y cuando llame al WebService, VS.2005 se parará en
los BREAK-POINTS que hayas puesto en el WebSerevice o en los componentes de
negocio.

En cuanto a la identidad de los Thread, por defecto dentro de un mismo
proceso de aplicación cliente (WinForms) va a ser siempre lal misma a no ser
que lo hubieras cambiado tu explícitamente. O sea, que no tienes problema en
este caso (si he entendido correctamente tu duda).
Donde la identidad puede ser diferente es p.e. en un WebService si hay
impersonación, porque el WS crea diferentes hilos y las llamadas son/pueden
ser originadas por diferentes usuarios, etc.
CESAR DE LA TORRE
Software Architect
[Microsoft MVP - XML Web Services]
[MCSE] [MCT]

Renacimiento
[Microsoft GOLD Certified Partner]


"AOG" wrote:

hola, tengo un par de dudas

1º duda:
tego una solucion en VB 2005 final, formado por 4 proyecto 1º es la capa de
IU (Interfaz de Usuario), 2º un SW (Servico Web), 3º es la capa de negoacio y
4º Acceso a datos.
la solucion está en modo Debug, y pregunto por qué, y son muy poca veces, me
funciona ir depurando (interpretando)las líneas de código pasa por paso (F8)
empezando por el proyecto IU y me pasa al proyecto SW y sigue interpretando
linea por linea para ver el
conportamiento en la capa de negocio, y en la mayoria de veces
no me deja depurar, es decir se queda en el proyecto IU y no sigue
interpretando las
lineas de los demas proyectos, continuando en la siguiente linea del
poryecto IU, una vez
terminado la llamada al método del servico Web, vamos que no interpreta
paso a paso por lo demás proyecto. ¿Tengo algo mal configurado en mi VS?

2º duda
Otra cuestion es si desde la capa IU se hace una llamada un metodo del SW
el Thread.CurrentPrincipal es el mimo o conserva los mismos valores en todas
las llamadas,
hasque que se cambie en ese hilo de ejecusion. Lo digo por la seguridad ya
que tengo hecho
que en cada llamada de un metodo del SW la primera línea es recoger el
usuario y contraseña
de la cabecera SOAP y llamar a una funcion que si ha cambiado el
Thread.CurrentPrincipal.Identity.Name vuelvo
a buscar el usuario en la base de datos y comparar el que se pasa por la
cabecera
y permitirá o denegará continuar ejecutando el metodo si el usuario es
válido, si es
valido asigno el usuairo de la cabecera SAOP al
Thread.CurrentPrincipal.Identity
y en el caso que Thread.CurrentPrincipal.Identity.Name
es igual a la de la cabecera no busco en la BBDD y me ahorro acceder a la
BBDD.

Public Function ValidarUsuario(UsuarioActivo_CabSOAP,ClaveActivo_CabSOAP) as
Booleand
if Thread.CurrentPrincipal.Identity.Name <> UsuarioActivo_CabSOAP Then
dsUsu = BuscarUsuarioEnBBDD(UsuarioActivo_CabSOAP)
if dsUsu.Rows(0).Codigo = UsuarioActivo_CabSOAP and dsUsu.Rows(0).Clave =
ClaveActivo_CabSOAP then
AsignarNuevoUsuairoCurrentPrincipal(UsuarioActivo_CabSOAP)
return = true
else
return = false
end if
Else
return true
End if
End Function
¡Claro!, esto me sirve si conserva Thread.CurrentPrincipal.Identity.Name en
todas las llamadas
, en el caso que no, siempre estaría buscando en la BBDD, lo cual el
rendimiento será peor.
Si se accede directamente desde la IU a la capa de negocio si es el mismo
Hilo, pero cuando
hay un SW por medio, ignoro el comportamiento.

Lo que se trata de guardar el usuario activo en el SW para compara con el
que se pasa en
la cabecera SOAP cuando se llama a un metodo del dicho SW.
Si alguien me puede aportar una sugerencia mejor sobre este tema de
seguridad, se lo agradecería mucho.

Por favor, me gustaria que me despejarais estas dos dudas, un saludo.

Preguntas similares