DotNetClubs

Hola primero gracias por leer mi post, bueno mi problemilla es el siguiente tengo un webservice con un grupo de metodos dentro de los cuales hay uno que me permite autenticar a un usuario, una vez autenticado adiciona crea una variable de session y adiciona un objeto con la info del usuario que se autentico, una vez hecho esto llamo a otro metodo dentro de mi servicio web y puedo leer el objeto que se agregó en la sesion hasta ahi todo bien, el problema se da cuando hago un llamado a estos servicios web desde un webpart exactamente donde hago esto:

this.Context.Session['miVar']="Valor";

se genera el siguiente error en el webpart

object reference not set to an instance of an object.

de antemano muchas gracias por la ayuda ...

 Hola Jimenes,

Solo decirte que tienes un error de concepto.

Los WebServices son sin estado, por lo tanto, deberias verificar el usuario y la contraseña en cada invocación a una operación.

Aunque lo mejor es que lo modeles la seguridad como un aspecto de tu arquitectura y delegues a la plataforma la autenticación. Y solo obtengas los datos de seguridad ya autenticados para identificar al cliente. Esto ultimo lo harías por cada operación.

Saludos 

Hola Carofe,

Con Servicios Web ASP.NET sí se puede gestionar automáticamente el estado mediante

        [WebMethod(EnableSession=true)]

De todos modos, no está recomendado, y cito del artículo  Top Five ASP.NET Web Services Tips, de Alex Ferrara, co-autor de Programming .NET Web Services
:

 Tip 5: Avoid ASP.NET Session State if You Can

While .NET's implementation of session state solves a number of the problems found in its ASP 3.0 predecessor (for example, request serialization, reliance on cookies, and lack of support for Web farms), it still suffers from several drawbacks. You should realize that it was not designed specifically for managing state in Web service applications, but rather for managing state in ASP.NET applications in general, and as a result, it relies on HTTP cookies (there is also an option to use a cookie-less mode that uses munged URLs, not compatible with a Web service). Cookies are HTTP specific, and while fine for the Web, where all browsers support them, using them in your Web services ties you to the HTTP protocol. SOAP is designed to work independently of the transport protocol, so tying your application to HTTP limits your flexibility and may create a lot of additional work for you down the line if you need to provide services over a transport protocol other than HTTP (for example, SMTP).

A better approach to managing state is to use a ticketing system implemented as metadata in a SOAP header. You can learn more about this technique in Chapter 5, "Managing State," of Programming .NET Web Services.

 Espero que ayude, un saludo.

 Hola:

Tecnológicamente es posible, pero conceptualmente no es recomendable.

Fijate en lo que pongo aquí:

http://www.dotnetclubs.com/forums/t/194.aspx

 Partiendo de que no puedes asegurar que el desarrollador mantenga la sesion HTTP activa.