(Esto es de junio 2005)
Sitio web: inmabb.criba.edu.ar/catalis/
Versión local en: /var/www/html/catalis/ Acceso a naposta.criba.edu.ar por FTP (user: inmabb) Estructura: /catalis/ /dl/ archivos para descargar (.zip, .tgz) /img/ /instalacion/ guía de instalación /img/ La guía de instalación (original) se aloja en /var/www/html/catalis/instalacion/
Sitio local para desarrollo de Catalis: 127.0.0.1 (fgomez03)
catalis_pack: la versión "estable" más reciente catalis_pack_devel: la versión de desarrollo, inestable catalis_pack_old: vestigios de versiones viejas, pruebas, etc. catalis_pack_test: prueba de una instalación /var/www/html/ /catalis_pack/ /catalis_pack_devel/ /catalis_pack_old/ /catalis_pack_test/ /var/www/cgi-bin/ /catalis_pack/ /catalis_pack_devel/ /catalis_pack_old/ /catalis_pack_test/ /var/www/bases/ /catalis_pack/ /catalis_pack_devel/ /catalis_pack_old/ /catalis_pack_test/
Catalis en catalis.uns.edu.ar (LinuxBC)
¿Podemos evitar que las bases de producción queden expuestas a través del demo? Quitemos el usuario XX de la versión de producción, y dejémoslo como único usuario en el demo. Qué DATOS - Qué APLICACION - Qué USUARIOS catalis_pack: la versión "estable" más reciente (producción) catalis_pack_devel: la versión de desarrollo, inestable /home/catalis/html/ /catalis_pack/ /catalis_pack_devel/ /home/catalis/cgi-bin/ /catalis_pack/ /catalis_pack_devel/ /home/catalis/bases/ /catalis_pack/ produccion (datos de verdad!!) /catalis_pack_devel/ desarrollo (pueden ser las bases del demo) /catalis_pack_demo/ bases accesibles mediante el demo
Preparación de las distribuciones para bajar (linux/windows)
Ubicación: /home/fernando/catalis/distribuciones/ Los archivos se copian desde /var/www/*/catalis_pack*, se añaden los archivos auxiliares (LEAME, LICENCIA, instalacion), y todo se ubica en 'linux/nueva'. Al ejecutar el script unix2dos.sh, se crea una copia en 'windows/nueva'. También deben generarse los archivos comprimidos.
/home/fernando/catalis/distribuciones/ unix2dos.sh /linux/ /nueva/ /catalis-20050609/ catalis-20050609-linux.tar.gz /windows /nueva/ /catalis-20050609/ catalis-20050609-windows.zip
Estos archivos (.tgz, .zip) luego se copian a /var/www/html/catalis/dl/ y se suben al servidor (naposta.criba.edu.ar). Al generar una nueva versión, se deben modificar varias páginas: main.htm, download.htm, etc.
Sitio para testeo de distribuciones (windows & linux)
Para testear la instalación de una nueva versión, sin afectar a las versiones ya instaladas, podemos trabajar con directorios catalis_pack_test, tanto en Linux como en Windows, y ajustar el catalis.conf correspondiente.
El wiki
URL: http://catalis.uns.edu.ar/wiki/ Acceso vía Web. ¡Resolver el problema del backup!
El grupo de Google
URL: http://groups.google.com.ar/group/catalis
http://groups-beta.google.com/group/catalis
En casa mejor desarrollar con Linux, para evitar todos los problemas conocidos (excepto para el testeo de las versiones Windows, o el desarrollo de un .bat). ¿Y cómo usamos IE? Instalar Win4Lin! (Pero primero, pasemos a Ubuntu).
Resolver: Backups y transferencia uns/home
¿Codificación? UTF-8 ??
Ideas sobre autenticación en Catalis
Situación actual:
En catalis.xis tenemos la sección <label>AUTHENTICATE</label>, que se ocupa de comparar los valores de userid y pw recibidos desde el cliente con los valores almacenados en la base users. Si la comparación falla, se vuelve a presentar el formulario de login; en caso contrario se presenta la pantalla principal de la aplicación. Esta incluye varios formularios con method=“post” y
<input type="hidden" name="userid" value="[pft]v2002[/pft]">
De esta manera, cada vez que se vuelve a invocar catalis.xis por medio de tales formularios, el script recibe el userid. Hay una verificación mínima: si no recibe un userid, se aborta el script. Pero si lo recibe, ¡lo considera correcto, sin más verificación! Esto permite que se puedan realizar peticiones en nombre de un usuario que no haya iniciado debidamente una “sesión” en Catalis, con sólo incluir un parámetro userid en la petición. Más aun: ¡el userid puede ser *cualquiera*, aunque no corresponda a ningún usuario real!
Para poder generar una petición que escriba datos en una base, debe proveerse el nombre de una base existente, y debe proveerse un userid que tenga permiso de escritura para dicha base.
Un primer nivel de “seguridad” que se puede añadir a este esquema consiste en generar un “token” al momento del login, y entregarlo al cliente en una cookie (válida solamente hasta que se cierre la ventana del navegador). Esa cookie será reenviada al servidor con cada petición subsiguiente, y permitirá verificar que corresponde a una sesión iniciada por el usuario userid.
Para no estar cayendo nuevamente en la situación anterior, necesitamos que no sea trivial fingir una petición auténtica, esto es, que el valor de la cookie (el token de autenticación, de validez temporal) no sea sencillo de adivinar. Tendríamos que poder generar algún string aleatorio, y (en el peor de los casos) usar algún string basado en el timestamp del login más el número de IP del cliente al momento del login.
Por otra parte, el valor de esa cookie debe ser leido por el script del servidor y comparado con el valor almacenado en …? ¿Dónde almacenamos en el servidor los identificadores de sesión? Puede ser en la base users, en el registro del usuario correspondiente, o bien en una base especial llamada sessions.
¿Qué sucede si desde un mismo cliente se inician dos sesiones, usando dos ventanas del navegador?
¿Cómo es el mecanismo de “caducidad” de las cookies (en el cliente y en el servidor)? ¿Desaparecen del cliente luego de cerrar la ventana, o siguen allí pero no son enviadas al servidor? ¿Necesitamos en el servidor saber si se ha recibido una cookie caduca? Si la sesión es finalizada con el botón “Fin sesión”, entonces puede matarse la sesión en el servidor; pero en caso contrario …?
Si usamos cookies, ¿ya no es necesario seguir pasando el parámetro userid a través de los formularios? Esto tiene relación con la pregunta previa sobre dónde almacenar los identificadores de sesión. Si usamos una base de sesiones:
1 sessionID identificador de la sesión 2 userid usuario que inició la sesión 3 IPnumber el IP desde el cual se accedió (puede no ser constante a lo largo de una sesión?) 4 beginTimestamp inicio de la sesión 5 endTimestamp fin de la sesión (puede no estar)
Al diccionario de la base session necesitamos enviar el sessionID, pues ese será el dato que recibamos en las cookies del cliente, y con ese dato debemos verificar:
Wiki:
http://es.wikipedia.org/wiki/Wikipedia:Edici%C3%B3n_referencia_r%C3%A1pida http://es.wikipedia.org/wiki/Wikipedia:C%C3%B3mo_se_a%C3%B1aden_im%C3%A1genes http://es.wikipedia.org/wiki/Wikipedia:C%C3%B3mo_puedo_colaborar http://es.wikipedia.org/wiki/Wikipedia:C%C3%B3mo_empezar_una_p%C3%A1gina http://es.wikipedia.org/wiki/Wikipedia:C%C3%B3mo_se_edita_una_p%C3%A1gina http://es.wikipedia.org/wiki/Wikipedia:Ayuda http://es.wikipedia.org/wiki/Wikipedia:COMOs
Indicaciones para instalar una nueva versión de Catalis
Si usted ya tiene una versión previa de Catalis instalada, siga estos pasos:
1. Haga un backup de sus bases de datos (bases/catalis_pack/catalis) 2. Elimine CGI-BIN/catalis_pack (pero preserve catalis.conf y wxis) 3. Elimine DOCUMENT_ROOT/catalis_pack 4. Elimine BASES/catalis_pack 5. Copie las carpetas de la nueva versión tal como se indica en … 6. Restaure sus bases de datos, catalis.conf, y wxis
Guía de instalación - Diferencias entre Win/Lin
Obtención de Catalis * Obtención: link a tgz
Software requerido * Sistema operativo: ? * Servidor web: testeado con Apache * Descompresor: no hace falta mencionar
Instalación * Descompresion * Copiar carpetas * Editar catalis.conf * Permisos de escritura: podemos mencionarlos explícitamente
Prueba de la instalación Acá hay una diferencia importante: la PC desde donde se hace la prueba quizás no sea la misma de la instalación (necesita IE)
catalis desarrollo