Depurador y CurrentPrincipal

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.

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.

Hola Cesar y Miguel, muchas gracias por vuestra aportacion.
Respecto a mi primera duda, he probado lo que me habeis dicho y funciona
correctamente.

Con respecto a la segunda duda, me ha comentado en un foro que utilice
Credentials en el modo de autenticación "Windows > integrada":
Dim sw As New localhost.Service
sw.Url = Me.TextBox1.Text
sw.Credentials = System.Net.CredentialCache.DefaultCredentials
MessageBox.Show(sw.HelloWorld())

..Dentro de la ejecucion (Hilo) del SW carga las credenciales el Principal
del Thread del SW toma los valores de las
credenciales que hayas puesto. Como cada usuario enviará las suyas (si
utilizas las DefaultCredentials), en cada llamada tendrás un Identity.Name
que se corresponda con el usuario que ha hecho la llamada.

He probado esto de esta manera, en la IU:
SWGestorMamatenimiento.Credentials > System.Net.CredentialCache.DefaultCredentials
Tambien he probado con esto, asignar el usario y clave directamente:
SWGestorMamatenimiento.Credentials = New Net.NetworkCredential(usuario,
clave)

Nota: SWGestorMamatenimiento es la instacia del SW en la IU

... y cuando se hace la parada BREAK-POINTS (ya si puedo hacer dicha
parada)
en el metodo del SW hago esto para comprobar que usuario hay:

<WebMethod(), SoapHeader("HeaderUsuario",
direction:=SoapHeaderDirection.InOut)> _
Public Function Autenticacion() As Boolean
Dim s As String = Thread.CurrentPrincipal.Identity.Name
End Function
y la variable es blanco (""), vamos que no tiene asignado un usuario
asignado

¿Sebeis sobre este tema?, ¿He hecho algo mal? , seguro que sí

Un Saludo.

Sobre los comentarios de Cesar matizo un par de cosas:
- Con respecto a la depuración, en VS2005, no es necesario realizar un
Attach To Process para poder depurar conjuntamente un proyecto WinForm y un
proyecto WebService que forman parte de una misma solución. Simplemente en
las propiedades de la solución (Solution Explorer -> Solución -> (Menú
contextual) -> Properties) en Startup Project->Multiple startup projects,
puedes indicar que proyectos se inician cuando realizas la depuración,
puediendo indicar algunos de ellos que se inicien pero sin depuración. Esta
última opción es util si por ejemplo te quieres centrar solo en depurar la
capa de WebService, sin parar en los puntos de interrupción que tienes
definidos en el proyecto WinForm.
- Con respecto a la identidad del usuario, en una llamada a un WebService,
no se mantiene la identidad del usuario Windows desde la aplicación WinForms
hasta el proceso que gestiona el WebService, salvo que se utilice alguna
extensión SOAP que lo haga, y de esto seguro que Cesar sabe indicar mejor
que yo, no se si WSE tiene alguna extensión para esto. Son contextos
completamente distintos, ya que si así fueran los usuarios windows que
utilizan la aplicación WinForms, deberían existir en el servidor que
mantiene el WebService. Tienes que tener mucho cuidado con esto, por que
puede que implementes algún tipo de impersonalización en la maquina de
desarrollo, todo te funcione correctamente, y cuando subas el WebService a
un servidor de producción, empiece a fallar.
Un Saludo,

Miguel Angel Campos
MCAD.NET

"CESAR DE LA TORRE [MVP]" escribió en el mensaje
news:
> 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.