COM Interop: Objetos COM VFP y ASP.NET

Artículo original: COM Interop: VFP COM objects and ASP.NET
http://www.eps-cs.com/VFPConversion/ConversionBlog.aspx?messageid=8a84c7ee-7407-4f37-8082-c8ca71a02213 
Autor: Claudio Lassala (lassala@foxbrasil.com.br)
Traducido por: Ana María Bisbé York (amby@telefonica.net)
Para: PortalFox (http://www.portalfox.com)

Muchos desarrolladores VFP se enfrentan a la necesidad de consumir componentes VFP COM en ASP.NET Web Applications o Servicios Web. Esta es, habitualmente una buena forma de reutilizar la lógica de negocio que ha creado a lo largo de los años en VFP. Sin embargo, cuando trabaja con la lógica de negocio de VFP accedida como un componente COM, tendrá que tratar también con la seguridad. Esto puede ser una trampa.

Digamos que puede crear un componente COM VFP que expone una regla de negocio que desea consumir en .NET. En este caso, una aplicación Web .NET trata de instanciar ese objeto (a través de COM Callable Wrapper, o CCW). Esto causa frecuentemente una excepción "System.AnauthorizedAccessException" debido a que el "usuario" (la aplicación Web) no tiene derechos de acceso a la carpeta donde está físicamente ubicado el componente COM.

Normalmente, el usuario al acceder a una aplicación Web (sin ninguna autentificación especial especificada) entra utilizando un usuario genérico de ASP.NET, que tiene derechos muy limitados en el PC. Para que trabaje la aplicación, el usuario ASPNET debe tener los derechos de lectura a la carpeta donde está el componente COM. Por tanto, para conseguir el acceso a un componente COM VFP desde dentro de .NET, debe asegurarse de que la cuenta de usuario de ASPNET tiene garantizado el acceso a esa carpeta. Además, asegúrese de que NO tiene garantizados los derechos de escritura a la carpeta.  En general va a querer configurar los derechos de acceso para esa cuenta tan bajos como sean posibles para prevenir ataques de hackers. Además, especificar los mínimos derechos de lectura posible. Por ejemplo, ¡no permita derechos de lectura a un disco duro en su totalidad!

Existe una vía para evitar el enredo de mezclar las cuentas de usuario ASPNET: los componentes VFP COM pueden ser registrados en COM+ (una tarea que requiere solamente algunos clics y no implica cambios de programación). En COM+, puede especificar una cuenta de usuario específico que es utilizada para ejecutar el componente. De esta forma, se  puede crear una cuenta de usuario especial y utilizarla con el objetivo solamente de interoperabilidad. Debido a que esa cuenta tiene acceso al componente, no se requieren  otros cambios en el sistema de seguridad y la cuenta de usuario ASPNET se mantiene bloqueada, y por tanto, limita el área de ataque que tiene para trabajar el hacker. La parte negativa de este proceder son los gastos de tener introducidos ambos, en términos de administración y rendimiento. No obstante, es el proceder recomendado.