blog counter
January 2007 - Artículos - SkunkWorks

January 2007 - Artículos

Que es peor: buenos programadores o malos programadores?

Axioma: Malos programadores hacen huecos en la seguridad del software, y buenos programadores los encuentran y los explotan. . . Así que cual es peor?

Sujeto: El Modelo de Objetos de SharePoint 2007

Paradigma: Buscando en los rincones escondidos del nuevo Modelo de Objetos de SharePoint 2007, he encontrado una propiedad que permite mostrar en pantalla la contraseña (password) del administrador. Todo lo que se necesita es 4 renglones de código:

    SPWebApplicationCollection CollectionApplicationsWeb = SPWebService.ContentService.WebApplications;
    SPWebApplication oneApplicationWeb = CollectionApplicationsWeb["SharePoint - 80"];
    SPApplicationPool myAppplicationPool = oneApplicationWeb.ApplicationPool;
    Console.WriteLine("Yo soy '" + myAppplicationPool.Username + "' y mi clave es '" + myAppplicationPool.Password + "'");

Y el resultado es ... espeluznante:

(Note que la contraseña está protegida por todas partes, inclusive en la pantalla de IIS, desde donde ni siquiera se puede copiar con ctl+c, como el aviso indica).

Postulado: este es un hueco de seguridad más grande que el que tiene el monte Erebus (a que nadie sabe en donde queda el monte Erebus... no lo busquen, yo se los cuento: es en donde esta Appassionata von Climax en este momento)... estoy pensando que a metidas de pata en software habría que darles nombres como a los huracanes; desde este momento, podemos hablar del "Bug Erebus" para referirnos a esta forma de ver contraseñas de Windows... Además, Erebus fue el hijo de Caos, por lo que el nombre me parece bastante adecuado.

Escolio: A ver cuánto tiempo pasa antes de que un buen programador encuentre la forma de explotar el hueco. Hay un par de barreras a vencer, pero por eso tiene que ser un buen programador. Además, aunque Microsoft se de cuenta que metió las patas (demasiado tarde), y elimine esta propiedad del Modelo de Objetos, ya sabemos que las contraseñas están por ahí, en alguna parte, y simplemente habría que buscarlas un poquito más para encontrarlas.

Corolario: Hay alguien por ahí con línea directa con los dioses en Redmond? Yo les puedo enviar una docena de E-mails contándoles del asunto, pero de todas formas no me van a hacer caso, pero de pronto a alguien con buenos contactos por esas altas esferas si le hacen caso... Fuera de chistes, esto es serio señoras y señores, bastante serio...

Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...

Publicado por Gustavo Velez con 18 comment(s)

Cuantos errores se pueden cometer en 15 líneas de código?

(7 según Microsoft, y así se evitan leer todo la retahíla --> Ultima actualización: son 8, no siete)

Según las teorías sobre escritura de código, está permitido algo así como un error en cada 100 líneas de código, si no me equivoco, y desde que no sea un error de lógica, pues de esos no queremos ni que nos los mencionen.

Pero cuantos errores puede cometer Microsoft? Hoy he estado probando cosas por aquí y por allá de SharePoint 2007, dándome la oportunidad de mirar con calma el nuevo SDK. Una de las cosas que más me ha llamado la atención de la nueva versión es la posibilidad de exportar sitios completos desde código, así que me fui derecho a la sección correspondiente y empecé a seguir el ejemplo que el SDK muestra. El asunto es tan poderoso, que con 15 líneas de código se puede exportar e importar sitios completos; el código del SDK es el siguiente:

1 using Microsoft.SharePoint.Administration;
2 using MicroSoft.SharePoint.Deployment;

3 SPExportSettings exportSettings = new SPExportSettings();
4 exportSettings.SiteUrl = "http://webname";
5 exportSettings.ExportMethod = SPExportMethodType.ExportAll;
6 exportSettings.BaseFileName = "exportfile";
7 exportsettings.FileLocation = @"c:\";
8 SPExport export = new SPExport(SPExportSettings);
9 Export.Run();

10 SPImportSettings importSettings = new SPImportSettings;
11 importSettings.BaseFileName = "exportfile";
12 importSettings.FileLocation = @"c:\";
13 importSettings.SiteUrl = "http://newweb";
14 SPImport import = new SPImport(SPImportSettings);
15 Import.Run();

Mi sorpresa (todavía me sorprendo de algo hecho por Microsoft?) es que en 15 líneas de codigo hay siete 8 con errores. Fíjense, por ejemplo en la línea numero 2: ni siquiera los empleados de Microsoft saben escribir el nombre de la empresa correctamente ("MicroSoft"). Linea 7 dice "exportsettings", línea 9 dice "Export" (el objeto es "export") y línea 15 dice "Import" (el objeto se llama "import").

Pero bueno, esos son errores de meter el dedito en el sitio equivocado y de los que el compilador nos avisará que hay algo mal (pero no lo que es). Lo malo empieza a verse en el renglón 10, en donde el objeto "importSetting" utiliza un método como constructor sin paréntesis. Pero eso también se les puede pasar. En donde te quedas sin ganas de seguir es en los renglones 8 y 14, en donde intentan utilizar una clase como parámetro de un constructor... simplemente cerrar e irse a acostar… si esto es el SDK, que esperanzas nos quedan...

PS: Para los incrédulos, el código del SDK se puede ver On-Line (http://msdn2.microsoft.com/en-us/library/ms438819.aspx), con exactamente los mismos errores... Hay alguien por ahí con conexión directa con los dioses en Seattle para que les avise? siete 8 errores en 15 líneas de código es un poquito demasiado...

PS: otro encontrado al ejecutar el código: la exportación produce un archivo con extensión .cmp automáticamente, pero al intentar importarla, en el renglón 11 es necesario utilizar el nombre del archivo Y su extensión, no como el SDK pretende (sin extensión).

Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...

Publicado por Gustavo Velez con 6 comment(s)

Primera conferencia europea de SharePoint

El 12, 13 y 14 de febrero 2.007 se realizará la primera Conferencia Europea de SharePoint en Berlín (Alemania) https://live.sharepoint-conference.eu/EN/Pages/default.aspx. La Conferencia consistirá de más de 50 lecturas, mesas redondas, y, por supuesto conferencias (de otra forma no sería una Conferencia).

Si alguien va por esos lados, y tiene ganas de tomarse un café y charlar un rato sobre SharePoint, la situación mundial y lo que nos de la gana, con gusto nos podemos ver allí. Envíenme un E-mail, y convenimos un punto de encuentro.

Nota: después de la conferencia oficial hay otro día (15 de febrero) solamente sobre Groove, que puede ser interesante.

Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...

Publicado por Gustavo Velez con 1 comment(s)

En que nos estamos metiendo, en el nombre de todos los dioses...

Esta mañana, en medio de una fila infinita en la autopista, por eso del aburrimiento y por hacer algo más útil que solamente mirar a los otros "knowledge workers" sentados en sus autos esperando a salir de la fila, me he puesto a leer un artículo de Mike Gunderloy ("Revolution Time Again"), uno de mis columnistas favoritos.

El articulo habla sobre las revoluciones en desarrollo de software que hemos "sufrido" los últimos años: de DOS a Windows, de 16 a 32 bit, de Visual Basic 3/6 a DotNet. Yo agregaría algunas otras más: mi primer programa fue escrito en Fortran y programado en tarjetas perforadas... probablemente la mitad de las cuatro personas que están leyendo esto no tienen ni idea que es una tarjeta perforada (http://mx.geocities.com/aqilesboy2003/historiadelacomputacion/tipica.html, para que se enteren).

Pero bueno, el articulo se pregunta si vale la pena de meter un montón de esfuerzo en aprender a utilizar y programar con la nueva revolución de software que Microsoft nos está dando con el DotNet 3.0: Windows Presentation Foundation, Windows Communication Foundation, Windows WorkFlow Foundation, Office 2007... porque no darle un vistazo a Apple o al mundo de Unix/Linux, pero, sobre todo a aplicaciones Web.

Hace algún tiempo, en un arrebato de desesperación cuando el SDK de SharePoint 2007 fue publicado por primera vez, fuera de arrancarme los pocos pelos que me quedan en la cabeza, escribí algo por estos lados para sacarme un poquito la frustración (http://blogs.clearscreen.com/skunkworks/archive/2006/06/07/3069.aspx). El API de SharePoint pasó de cuatrocientas y algo clases a 1.260 con un numero que no quiero saber de métodos, propiedades y eventos. Poco a poco, y luego de usarlo casi un año, la desesperación se ha ido convirtiendo en conocimiento, y ahora estoy empezando a entender un poquito de que se trata el asunto de nuevo... así que cuando venga la nueva versión, dentro de dos o tres años, probablemente ya lo estaré conociendo más o menos bien, y tengo que empezar de nuevo (casi) desde cero... magnifico...

Por pura casualidad, en estos días también estuve filosofando con mi jefe sobre el mismo tema. Muchos de los clientes para los que trabajamos quieren que los proyectos se hagan a precio fijo, y mi jefe tiene problemas enormes para explicarles que los riesgos que implican hacer proyectos con tecnologías muy nuevas (la compañía hace bastante proyectos utilizando las betas de Microsoft), hace casi imposible trabajar a precio fijo: la información técnica es mínima, es necesario invertir mucho tiempo en probar, probar y volver a probar (muchas veces para encontrar que, simplemente, no es posible hacer lo que quieres), y la falta de experiencia hace que todo dure un tiempo indeterminado. Como argumento a favor, a mí se me ocurrió solamente que el conocimiento que nosotros recopilamos en un trayecto de este tipo lo podemos utilizar más rápidamente que la competencia: un "ventaja tecnológica"... Su argumento fue apabullante: el desarrollo tecnológico va a tanta velocidad, que cuando estamos listos con una tecnología, nos la cambian y tenemos que empezar otra vez desde el principio...

Así que el dilema continua: seguir corriendo detrás de la zanahoria, como el burro del proverbio para mantenernos en la "punta de la lanza", o parar por un tiempo, estabilizar lo que sabemos, y luego seguir con lo siguiente, corriendo el riesgo de volvernos viejos tecnológicamente...

Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...

Publicado por Gustavo Velez con 3 comment(s)

Paginas Maestras en SharePoint... mejor o peor de lo que esperaba?

Cuando se conocieron las primeras noticias sobre SharePoint 2007, una de las cosas que me hicieron saltar de alegría fue la posibilidad de usar Paginas Maestras. Una de las pesadillas al modificar la presentación de un portal de SharePoint 2003 es la cantidad de trabajo que hay que hacer para cambiar las cosas más mínimas; me acuerdo muy bien un proyecto de hace un par de años en donde tuvimos que cambiar 359 archivos para hacer que la intranet (SharePoint 2003) de un cliente tuviera la misma presentación grafica que su extranet. Por supuesto que en el transcurso del tiempo se han creado "soluciones" para arreglar el problema ("skinners"), pero ninguna funciona bien bajo cargas altas de usuarios.

Con las Paginas Maestras es posible realizar cambios en todo el Portal cambiando solamente una página (default.master)... genial... o casi. En realidad, no todas las paginas utilizan la misma Pagina Maestra: solamente las páginas de contenido la utilizan. Todas las páginas del "sistema" (las páginas de administración, por ejemplo) se niegan rotundamente a utilizarla pues usan la suya propia (application.master). Pero bueno, se podría pensar, es mejor cambiar dos páginas a cambiar 359... El problema es que en la administración del Portal se puede definir que Pagina Maestra se debe usar en el Portal, o, mejor dicho, en las páginas de contenido del Portal, pero no se puede definir lo mismo para las páginas del sistema. Así que, al final tendremos dos diferentes layouts: uno para contenido y otro para administración; el primero se puede modificar para cada sitio independiente, y el segundo es para todo el sistema... se comprende? No?... yo tampoco lo comprendo...

Una metida de pata de nuestros amigos en Seattle, una oportunidad desperdiciada o un NDI ("Non Documented Issue", aunque si está documentado en el SDK)?. Probablemente nunca lo sabremos definitivamente. Pero ahora hay que buscar alguna forma para salirse del problema: como modificar algo que sucede en todo el Portal desde un sitio único, sin tener que pasarse el resto de vida programando... un HttpModule, pensaría yo. No son difíciles de programar, ahora que SharePoint no utiliza un filtro ISAPI funcionaran probablemente de una forma más estable, y se pueden configurar para que cada sitio utilice su propia Pagina Maestra para contenido Y sistema.

Provisionalmente hablando (no lo he probado aun con seriedad), el código debería ser algo parecido a:

public class MiModuloParaPaginasMaestras : IHttpModule
{
   public void Init(HttpApplication context)
   {
     Page miPagina = HttpContext.Current.CurrentHandler as Page;
     if (miPagina.MasterPageFile.Contains("application.master"))
     {
       miPagina.MasterPageFile = "/_catalogs/masterpage/miPaginaMaestra.master";
     }
   }
}

Es decir, cada página que envía un request a IIS es interceptada por el HttpModule, y si tiene un "application.master", se le cambia por un "miPaginaMaestra.master". Hasta ahora solamente he visto que funciona, pero el código no está listo para ser usado en producción. Varios problemas se pueden presentar aquí, y todos tienen que ver con las Paginas Maestras mismas:

- Hay dos formas para crear y modificar Paginas Maestras: a "lo mero macho", como dirían mis amigos los mexicanos, es decir escribiendo el código como se debe (código http, mas código xml, mas código CAML... en realidad, algo para los que saben lo que están haciendo), o usando el nuevo SharePoint Designer (facilito de hacer, pero se pierde totalmente el control sobre lo que pasa con el código). Desafortunadamente el Designer tiene una historia desastrosa de 10 años de mal-funcionamiento (cuando todavía se llamaba FrontPage)

- No hay forma de depurar Paginas Maestras: si se comete un error, el sitio simplemente deja de funcionar. Lo único que se puede hacer por ese lado es cambiar las propiedades del web.config respectivo para mostrar una indicación del problema en pantalla.

En resumen y para terminar. Las Paginas Maestras en SharePoint 2003 son una mejora (hasta una mejora enorme, se puede decir), pero les falto correr la ultima milla para hacerlas funcionar perfectamente... así que ellas son mejor y peor de lo que esperaba.

Gustavo - http://www.gavd.net/servers/
Escriba un Comentario que me haga reir...

Publicado por Gustavo Velez con 1 comment(s)