Buenas!

Quería hacer una consulta por una cuestión que surgió luego de migrar de G2 a G3.
Algo que les habíamos consultado en reuniones previas a la migración era la necesidad de separar materias que en G2 compartían código entre propuestas pero no eran equivalentes (se había parametrizado de esa forma).

Dado que en G3 la acreditación de actividades entre propuestas es transparente, lo que se hizo fue crear nuevas actividades en las versiones nuevas de los planes. A partir de ello, la vieja actividad quedó en la versión original y se crearon matrices entre versiones para acreditar esos cambios.

Por ej.: Matemática (80003) estaba incluída como actividad en "Música y Tecnología (G1)", plan 2015 v1 y "Licenciatura en Informática (W)", plan 2015 v1. En el versionado se incluyeron las actividades 8003C para G1 v2, y 8003N para W v2. Luego, se crearon las matrices de equivalencia correspondientes para respetar la acreditación de la actividad según el origen.

El problema que surgió con este procedimiento es que, al aplicar las matrices (utilizando "Procesar matrices de equivalencia") no respetó la propuesta de origen de aprobación. Como resultado de ello, vemos que se acreditaron actividades que no se corresponden con el origen estipulado en la matriz.

Un caso testigo puede ser el de un alumno matriculado en G1 y W, que acredita la 80003 por Música V1 y, al correr las matrices, se le otorga la 8003C como así también la 8003N.

¿A qué se debe este comportamiento? ¿Puede tener que ver con la manera en que se ejecutaron las matrices?

Adjunto captura de una de las dos matrices que mencionaba en el ejemplo.

Saludos y gracias!

Estimados, les comento una cuestión que detectamos luego de una auditoría de seguridad, nos pareció bastante grave y lo queremos reportar a la comunidad.

La cuestión es que corriendo el servlet como se indica en la wiki: https://repositorio.siu.edu.ar/trac/Portal-G3/wiki/NotasTecnicas/InstEntornoDesa el servicio termina escuchando para todas las direcciones IP del servidor.

Si este servidor tiene alguna IP de acceso externo puede significar acceso a parte o todo el filesystem, dependiendo de como se ejecute.

Nuestra primer opción fue utilizar iptables para cerrar el acceso al puerto 8081 con origen distinto a loopback. No siendo lo ideal buscamos un poco y encontramos que una opción no documentada es especificar "SERVLET_LOCAL" en lugar de "SERVLET". Eso hace que el servicio corra solamente sobre la interfaz loopback.

Finalmente así quedo:

cd $guarani_dir\lib\toba\php\3ros\JavaBridge\WEB-INF\lib\ ; sudo -u nginx java -jar JavaBridge.jar SERVLET_LOCAL:8081 &
Nota: La parte '-u nginx' es para correr el servicio con el usuario del server http, en nuestro caso "nginx", en el de la mayoría supongo será "apache".

Sugiero cambiar la documentación de la wiki respecto a este punto.

Saludos,

Ramiro