Hola estimad@s lectoras. Aquí esta Gnoblis de nuevo aburriéndolos como ostras con una entrada que se acerca un poco a temas de programación que solo a el interesan como documentación de las cosas que hace y le parece interesante guardar como auto-consulta a futuro. Si a alguien también le sirve y/o interesa es puro daño colateral, así que discúlpenme por no poner un tutorial claro con ejemplos y todos los enlaces.

¿Recuerdan que les dije que la semana pasada fue pesada? Si, pero al menos hubo una cosa interesante. Pasar páginas construidas hace años a servidores Linux. En su tiempo Mono estaba muy verde y se hicieron en Windows pero les llego su hora. Una de las ventajas que se dicen de .NET es su portabilidad semi-artificial porque es dependiente del Proyecto Mono, y sin entrar en detalles sobre las ventajas de otras tecnologías como PHP o JAVA -qué indudablemente se que tienen y he aprovechado en algunos desarrollos, como todo lo que ya esta hecho en PHP y lo combinable que es cuando necesitas controles personalizados- por ejemplo o mantenerse puro e incontaminado de todo contacto con Microsoft y cosas así. Esas son otras historias y aquí solo me dispongo a hablar de una experiencia pasando algo hecho y funcional en lugar de empezar de cero algo nativo o mejor, aunque también me parece justo reconocer que con .NET hicieron algo bastante mejor que con las tecnologías sueltas que tenían antes como ASP o Visual Basic pero eso también es otra historia.

Centrándome en el tema, tenemos sitios web construidos con ASP.NET y C# como base aderezada de JavaScript y hasta algún ActiveX (que solo funcionan en el terrible IE, lo se, pero en un ambiente cerrado, interno y sin Internet puede resultar menos riesgoso) por ahí ¿Cómo habría de comportarse eso corriendo en Linux? Esa era la pregunta de una migración teóricamente posible pero de esas que podemos imaginar que nunca fluyen sin obstáculos pero el caso es que no sean irrazonablemente difíciles.

En Windows el entorno funciona nativamente combinando IIS + NetFramework. En Linux tenemos como opciones a Mono en lugar del NetFramework y en lugar de IIS tenemos a XSP como opción más sencilla pero de menor capacidad así que para probar estuvo bien pero no para confiar en eso para un ambiente productivo real así que la opción fue el siempre confiable servidor Apache complementado con Mod mono.

De Mono ya habré hablado antes en algunas entradas, y mod_mono es un módulo para que Apache pueda servir páginas ASP.NET usando a Mono, y funcional en Linux. No voy a explicar aquí como montar un servidor Apache, supongo que a quien le interese el tema debe manejarse lo suficiente para hacerlo o saber donde buscar… creo. Y además del Apache hay que instalar el módulo de Mono libapache2-mod-mono y la interfaz entre Mono y servidor mono-apache-server.

La página oficial de Mod mono es www.mono-project.com/Mod_mono, hay le buscan en la sección de descargas del sitio.

Bueno, una vez que tenemos montado nuestro server Linux con Apache y Mod mono podemos pasarle nuestra aplicación y empezar a probar, usando de preferencia la versión 2 de ASP.NET.

Antes de pasar la versión de la página compile y revise el código usando SharpDevelop y Mono 2.0 para asegurarme de ajustar lo que necesitara ajustar para mayor seguridad, pues en mi caso encontre que dice que la instrucción “ConfigurationSettings.AppSettings.Get” esta obsoleta. Actualizar eso fue fácil.

Invalid postback or callback argument

Lo que si requirió un poco más de investigación fue este error.

Invalid postback or callback argument. Event validation is enabled using in configuration or in a page. For security purposes, this feature verifies that arguments to postback or callback events originate from the server control that originally rendered them. If the data is valid and expected, use the ClientScriptManager.RegisterForEventValidation method in order to register the postback or callback data for validation.

Lo que en lengua común significa que hay una validación de seguridad en el Framework 2 que en 1.1 no existía y que revisa cuando se carga la página y si hubo un cambio sospecha que algo malicioso ocurrió del lado del cliente como un intento de ataque de inyección de código y que por eso los datos estan alterados, y por motivos de seguridad detiene todo y da ese aviso. Lo mejor es corregir el problema en lugar de desactivarlo como esta la alternativa pero en mi caso lo que ocurre es que tengo unos scripts del lado del cliente que cambian el valor de los controles en base a ciertas cosas y eso es lo que disparaba la validación. Así que mi solución paso por poner en la cabecera de la página afectada EnableEventValidation=”false” para que solo en esa página no hiciera la validación.

 <%@ Page EnableEventValidation="false" ... %>

En mi caso lo hice así porque este sistema trabaja en un ambiento interno y cerrado, con scripts controlados por nosotros y en un par de páginas bien identificadas. En caso de requerir que toda la aplicación funciones así es mejor ponerlo en el web.config para todo el proyecto.

<system.web>
	<pages enableEventValidation="false"/>
</system.web>

Bueno, con eso funciono la página excepto por los acentos que en lugar de poner la letra acentuada ponía un cuadrito, pero revisando las configuraciones regionales se arregla.