Diario de mi Proyecto : PFC sobre Moodle

  Archivos
Jul 07 [2]
Jun 07 [12]
Mayo 07 [13]
Mar 07 [3]
Nov 06 [6]
Oct 06 [5]


Sindicación
Artículos
Comentarios


Enlaces
eGrupos
ZoomBlog

 
Inicio | Mi Perfil | Suscríbete al blog
Junio del 2007

 

Applet de Java y memoria del pfc

Enlace permanente 30 de Junio, 2007, 16:01

Hola gente!

Pues ayer conseguí incluir la posibilidad de crear y ejecutar Applet de Java en el módulo. A punto he estado de tirar la toalla y no conseguirlo, pero con tiempo y paciencia, ha salido todo bien. El único problema es que le he dedicado demasiadas horas y estoy a tope de trabajo...

El módulo ofrece la posibilidad de crear Applets de Java, compilándose y ejecutándose en un pop-up del navegador donde se esté ejecutando el módulo. La única diferencia con respectos a los otros lenguajes, es que hay que pulsar el botón compilar antes de ejecutar el Applet desarrollado. Esto es así, porque para ejecutar el applet, redirecciono a un fichero applet.php que se encarga de crear el link que, una vez pulsado, lanzará el pop-up con el Applet.

Voy a comentar algo que tardé más de lo normal encontrar en Internet. Gcj compila exactamente igual, un applet de java que un programa en java. Para el caso de los applet la sentencia es:

gcj -C applet.java

Gcj creará el .class que será el que habrá que insertar en el fichero .html.

Y como hay bastante prisa, no comento nada más. Solo decir que me quedan dos días bastante duros terminando la documentación del pfc. También tengo que seguir investigando el tema de la ejecución remota, por ahora no tengo nada interesante.

En estos instantes estoy completando el apartado Análisis del sistema de la memoria del pfc.

Bye
Comentarios 39 ~ Comentar | Referencias (0)


 

Última entrega! (11º)

Enlace permanente 29 de Junio, 2007, 9:37

Ya llevo un par de días trabajando en la que será la última entrega de este proyecto.

Esta entrega se compone de muchísimos objetivos. El más importante y general es pulir y acabar de programar el módulo. Ahora mismo he realizado el siguiente trabajo:

  • Función compilar: he mejorado esta función, consiguiendo que se ejecuten los comandos necesarios de gcc para cada lenguaje. Ada ha sido eliminado debido a los errores con GNAT.
  • Opción enunciado: he creado una opción denominada Mostrar enunciado, para que el profesor decida si mostrar el enuncidado de una prueba desde en el momento que comience el examen o tenerlo visible siempre. Se ha incluido un botón de ayuda explicando la utilidad de esta opción.
  • Ficheros de ayuda en inglés: he creado todos los ficheros de ayuda en inglés.
  • Fichero idioma inglés: he traducido el fichero de idioma del módulo al inglés.
  • Cambio de nombre de actividad offline por actividad y examen por prueba.
  • Inserción del botón código: he insertado un botón llamado código. Este botón insertará un lenguaje predefinido (Hola mundo) en el lenguaje de programación del módulo.
  • Función reserve_words: esta función ha sido mejorada y cambiada de nombre a prohibited_words.
  • Ejecutables y fuentes en espacio de usuario: he mejorado la creación de fuentes y ejecutables. En este momentos los archivos se crean en el espacio de usuario del alumno que utilice el módulo.
  • Memoria del proyecto: he terminado los 4 primeros capítulos de la memoria, junto con el resumen y se los he enviado a Alberto para su posterior revisión.
Me queda por realizar:
  • Finalizar la memoria del proyecto: restantes capítulos, análisis, diseño, manual de usuario, programador, etc.
  • Documentación interna: revisar la documentación interna ya realizada.
  • Incluir lenguaje Applet Java: se va a dar la posibilidad de crear Applet de Java y ejecutarlos.
  • Funcionamiento en Linux: instalaré Linux en mi equipo para probar el funcionamiento de este sistema operativo.
  • Investigación: seguir con la investigación de la ejecución remota.
También he necesitado mejorar los botones de descarga de ficheros ejecutable y fuente, debido al cambio de almacenamiento de los mismos.  Esto me ha dado algún que otro problema ya que antes estaban en la misma ruta que la web, y con un simple formulario "action = nombre_ejecutable" funcionaba bien. Como esto me ha llevado mucho tiempo y ha sido complicado de descubrir, voy a poner el código exacto, para el caso del ejecutable, por si alguien lo necesita:

$dir = $CFG->dataroot.'/'.$course->id.'/'.$CFG->moddata.'/remoterunning/'.$remoterunning->id.'/'.$USER->id.'/'.'program.exe';
              if (file_exists($dir)) {
                      $filearea = $remoterunninginstance->file_area_name($USER->id);
                      $file = 'program.exe';
                      if ($CFG->slasharguments) {
                         $ffurl = "$CFG->wwwroot/file.php/$filearea/$file";
                      }  
                      else {
                         $ffurl = "$CFG->wwwroot/file.php?file=/$filearea/$file";
                       }
                       echo '  <td>';
                       echo '      <form enctype="multipart/form-data" method="post" '."action=\"$ffurl\">";
                       echo '      <input type="submit" name="download"  value="'.get_string("program","remoterunning").'">';
              echo '      </form>';
              }


No voy a entrar más en detalles del trabajo que he realizado en los primeros puntos, ya que necesito acabar toda la documentación para el martes y estoy bastante agobiado. Si alguien necesita ayuda, que me deje comentarios y le contestaré encantado.

Bye.

Comentarios 29 ~ Comentar | Referencias (0)


 

Entrada de datos desde fichero

Enlace permanente 26 de Junio, 2007, 2:52

Hace unos días probé la entrada de datos a un programa desde un fichero.

Realicé un sencillo programa en C (program.exe), con una instrucción scanf y otra printf, mostrando el dato pedido. Luego creé un archivo con un único número (datos.txt), y al poner la instrucción:

program < datos.txt

Se mostraba el dato por pantalla. Realicé varias pruebas con varias instrucciones scanf, con enteros y caracteres, con string, etc., siempre poniendo en cada línea de un fichero el dato adecuado. Todas las pruebas que realicé fueron satisfactorias, e incluso redireccionando la salida a la vez también funcionaba, es decir, la instrucción:

program < datos.txt > salida.txt

Si los datos del fichero son incorrectos, no correspondiéndose con el tipo de datos esperado por el programa, los fallos que se producen son del mismo tipo que si se introdujeran por teclado erróneamente.

Me falta por invetigar la integración de la consola en el navegador.

Bye
Comentarios 27 ~ Comentar | Referencias (0)


 

SSH

Enlace permanente 25 de Junio, 2007, 23:22

Mal asunto para utilizar ssh a la hora de ejecutar remotamente un ejecutable en mi módulo.

Por lo que he estado viendo en los enlaces que pongo en referencias, ssh sirve para ejecutar programas remotamente, pero para ello es el cliente quien tiene que iniciar la sesión, no siendo posible abrir una sesión desde el servidor, pues uno de los requisitos es contar con un "daemon ssh" en el ordenador que se quiere conectar.

Tendré que ver si se puede integrar la consola con el navegador. Mañana comentaré sobre la redirección datos de entrada desde un fichero.

Referencias:

Sesión gráfica remota: http://www.riveonline.com/index.php/blog/show/Sesin_grfica_remota_UbuntuMandrake_con_ssh.html

SSh tricks:
http://en.jakilinux.org/apps/ssh-tricks/
Comentarios 22 ~ Comentar | Referencias (0)


 

Fortran y ADA

Enlace permanente 25 de Junio, 2007, 14:12

Acabo de perder más de 3 horas configurando el módulo para que funcione con FORTRAN...
Al principio pensaba que la causa era los dintintos tipos de FORTRAN que existen, 77, 90, 95, etc. He elegido 90 porque es actual. He probado con varios programitas típicos y aún así no funcionaba...

Después de analizar soluciones como tirar el ordenador por la ventana o a la piscina, he probado con instalar el paquete gfortran en otro ordenador y ha funcionado perfectamente.

No sé la causa de que no funcione en mi ordenador, pero bueno, eso no es problema. He configurado el módulo para que funcione bien y llame al compilador correctamente.

Y ya que estoy escribiendo, la sintaxis correcta de gfortran es:

  • Para compilar: gfortran -c code.f90
  • Para compilar y crear un ejecutable: gfortran code.f90 -o program
Si se quiere programar en una versión distinta, solo hay que cambiar la extensión del archivo asegurándose de que el código es el correcto para la versión que se necesite.

Esta tarde me pondré con el último lenguaje, ADA y actualizaré el artículo con los resultados.

Bye


ACTUALIZACIÓN

Está claro que hoy no es mi día... Otras tantas horas perdidas con gnat... Y lo peor de todo es que no funciona, nada de nada. Por ahora, ADA queda en suspenso. Hablaré con Alberto sobre este tema y tomaré una decisión.

¿Y cuál es el problema? Pues que si a gnat le paso el path de un fichero, no funciona. Así de simple y así de extraño. Y el módulo funciona con los path de los ficheros, no es posible trabajar solo con el nombre del fichero :-(

Comentarios 30 ~ Comentar | Referencias (0)


 

Botones de ayuda y compilación con gcj

Enlace permanente 25 de Junio, 2007, 9:53

He insertado botones de ayuda en la interfaz del módulo. Estos botones son fáciles de crear, simplemente hay que utilizar la función helpbutton() y crear el fichero de ayuda correspondiente. Los ficheros de ayuda se crean en la carpeta lang/carpeta_idioma/help/nombre_módulo. En el caso de remote running sería lang/es_es_utf8/help/remoterunning. Aquí se crean los ficheros html correspondientes.

Con el lenguaje Java he tendido el siguiente problema. La forma de compilar y crear un ejecutable con gcj es la siguiente:


gcj -o Foo --main=Foo Foo.java
Siendo el código el siguiente:

public class Foo
{
public static void main(String args[])
{
System.out.println("Hello.");
}
}

Es decir, el nombre del archivo tiene que ser el nombre de la clase principal y hay que pasarle el nombre de la
clase donde se encuentre el main. Para realizar esto correctamente he creado dos áreas de texto en la interfaz,
que se activarán cuando el lenguaje utilizado sea Java. En estas áreas, el usuario tendrá que indicar al sistema el
nombre que tendrá el fichero y el nombre de la clase main.

He tenido que modificar las funciones de llamada a la compilación y ejecución, añadiendo parámetros para recoger
el nombre del fichero y de la clase main.

Captura de pantalla con botones de ayuda y áreas de texto para el lenguaje Java:





Comentarios 25 ~ Comentar | Referencias (0)


 

Permisos en el módulo

Enlace permanente 23 de Junio, 2007, 2:23

Este artículo lo escribo para comentar un asunto muy importante de Moodle y de los módulos.

Recientemente he descubierto los permisos para aplicar a los módulos. No voy a entrar mucho en detalles, pues todo está más o menos bien explicado en la web de Moodle (a veces un poco cutre porque son traducciones literales del inglés...).

Los permisos en un módulo se crean para dar derechos a los usuarios del módulo. Estos usuarios son conocidos como roles en la plataforma. Un rol puede ser: administrador, profesor, estudiante, creador de un curso, etc. Más sobre roles pinchando en este enlace.

Mediante los permisos puedo establecer que sea solo el profesor el que tenga la capacidad de calificar a un alumno, que sea el administrador quien pueda eliminar o crear el curso, o que sea el profesor, etc., es decir, aplico derechos a los distintos roles de la plataforma. Los permisos también pueden diferenciar cada vista particular de un rol sobre el módulo, es decir, un profesor tendrá un vista distinta a un alumno en una tarea cuando, por ejemplo, haya que subir un archivo. El alumno verá el formulario de subida de archivos, pero el profesor no. Todo esto se consigue con la creación de permisos o capacidades en la actividad a desarrollar.

¿Cómo se definen estas capacidades? Hay que crear un archivo, denominado access.php, en la carpeta db del módulo. El nombre de la variable de los permisos, junto con los permisos, tienen que ser exactamente igual que el nombre del módulo. Por ejemplo, si quiero crear un permiso para que solo el profesor pueda calificar a los alumnos, el código será el siguiente:



<?php

$mod_remoterunning_capabilities = array(

    'mod/remoterunning:grade' => array(

        'captype' => 'write',
        'contextlevel' => CONTEXT_MODULE,
        'legacy' => array(
            'teacher' => CAP_ALLOW,
            'editingteacher' => CAP_ALLOW,
            'admin' => CAP_ALLOW
        )
    )
);

?>


Como se puede comprobar, el nombre de la variable y de los permisos es igual que el nombre del módulo (remoterunning). Más sobre permisos, capacidades y roles en este
enlace.

Estos permisos se generan en la plataforma cuando se instala el módulo. Para comprobar que un usuario particular posee los permisos que hemos desarrollado hay que entar en Moodle como administrador e ir a
Administración del Sitio>>Usuarios>>Permisos>>Definir roles. Posteriormente habrá que pinchar en el rol a comprobar.

Bye
Comentarios 29 ~ Comentar | Referencias (0)


 

10º Entrega

Enlace permanente 21 de Junio, 2007, 11:34

Hola,
pues en esta entrega tengo que comentar bastantes asuntos. Primero comenzaré con la programación del módulo, he realizado cambios en el módulo y he añadido clases para diferenciar los distintos tipos de actividad. He realizado cambios en la interfaz del módulo, documentación interna, he continuado trabajando en la memoria del pfc y he comenzado a investigar soluciones a la ejecución remota.

Programación del módulo

Para realizar una correcta programación de la actividad y conseguir una integración adecuada en Moodle, he decidido trabajar con clases y objetos. El módulo tendrá tres clases, una será la clase base, denominada remoterunning_base y las otras clases serán extendidas, es decir, clases que heredan de remoterunning_base y se denominan remoterunning_offline y remoterunning_uploadsingle

He tomado esta decisión porque el módulo está orientado de dos formas distintas. Una es para que los alumnos puedan compilar y ejecutar sus programas desde la plataforma. Será una tarea en la que el profesor no intervendrá, los alumnos la utilizaran en el momento que esté disponible.

La otra forma de utilizar el módulo será como un examen, los profesores podrán evaluar los conocimientos de programación a sus alumnos, el módulo da la posibilidad de subir el fichero fuente con los resultados, el profesor podrá calificar, recibirá un mail de aviso cuando los alumnos envíen sus ficheros, etc. Es muy parecida a la opción "subir un único fichero" de la actividad tarea.

En cuanto a la documentación del código fuente, he comenzado a realizarla. En cada fichero he introducido una pequeña cabecera, como la siguiente:

/**
 * Fichero para una vista particular de una instancia del módulo.
 * Contiene el código para escribir problemas y compilarlos o ejecutarlos.
 *
 *
 * @author Francisco Javier Rodríguez Martín
 * @version $Id: view.php,v 1.0 2007/06/14 16:41:20 mark-nielsen Exp $
 * @package remoterunning
 **/

Y cada función de la librería lib.php y de las clases creadas está comentada. Indico lo que hace cada función y para qué sirven los parámetros. Por ejemplo, para la función remoterunning_compiler($language,&$compiler,$route):

/**
 * Esta función devuelve el comando a ejecutar según el lenguaje
 * que se haya configurado el módulo
 *
 * @param $language El lenguaje de programación del módulo
 * @param &$compiler El comando final de ejecución
 * @param $route La ruta del fichero a ejecutar o compilar
 **/

Interfaz de la actividad

He realizado cambios en la interfaz del módulo, ahora aparecen la consola de código fuente al comienzo, los botones en medio y la consola con los mensajes al final. Cuando se inicia la actividad, solo aparecen los botones de compilar y ejecutar. Una vez que el usuario compila o ejecuta su código, al crearse los ficheros fuente y ejecutable, el sistema lo detecta y aparecen los botones de download pertinentes. He añadido también un botón de ayuda que explicará al usuario, para qué sirve cada botón de la actividad. Una captura de pantalla:




































Memoria del proyecto


He continuado estos días con el documento de memoria del proyecto. He realizado el apartado Planificación, en la que hablo sobre la metodología de programación y las fases de desarrollo del proyecto. Los siguientes apartados que realizaré son el análisis y el diseño de la actividad.

Investigación para la ejecución remota

Como último trabajo del módulo, tengo que investigar si es posible una ejecución remota de los programas escritos por los usuarios del módulo.

Si no existieran instrucciones de entrada, sería posible redireccionar a un fichero y mostrar la salida. Como se quiere controlar estas intrucciones, voy a  investigar varias cuestiones:
  • Intentar integrar la consola del SO en el navegador.
  • Investigar código de Eclipse para ver como redireccionan la consola.
  • Crear applet de Java con terminal de SO.
  • Redirección de entrada desde fichero.

A currar!

Bye
Comentarios 26 ~ Comentar | Referencias (0)


 

Módulo integrado!

Enlace permanente 17 de Junio, 2007, 12:44

Hola!
Pues después de tres días programando como un loco, he conseguido la integración absoluta en la plataforma!! Todas las funcionalidades básicas de Moodle se ejecutan adecuadamente, es decir, la calificación, subida de ficheros, envío de mail al profesor, apertura y cierre de la actividad, etc.

He conseguido la integración en la plataforma! Esto es muy importante porque era un objetivo esencial del proyecto!

Y como estoy a punto de tirar el portátil por la ventana, descanso y mañana continuo actualizando el blog. Comentaré aspectos de la programación del módulo. También voy a continuar con la memoria del proyecto y la documentación interna del módulo.

Bye
Comentarios 25 ~ Comentar | Referencias (0)


 

Reorganización del módulo

Enlace permanente 15 de Junio, 2007, 9:30

Hola!
Hace un par de días, me di cuenta que para conseguir ciertas características en Remote Running, tenía que comenzar a programarlo de nuevo, sirviéndome lo que llevo realizado hasta ahora. Las características que necesito controlar son la subida de archivos por parte de un alumno y la calificación de una entrega por parte del profesor.

Estas dos opciones requieren controlar muchos aspectos internos del módulo, por ejemplo, cada vez que un alumno suba un fichero, éste tiene que llegar al profesor pudiendo calificarlo. Cuando el profesor acceda al módulo se le mostrará una lista con los alumnos y sus respectivos archivos subidos, si están calificados o no, etc. Lo que realmente se califica es el problema que mande el profesor, no el archivo en sí, es decir, un profesor realizará un examen de programación, el alumno enviará un fichero como resultado del examen. Por lo tanto, el profesor, basándose en el fichero resultado, calificará el problema.

Con todo lo anterior quiero dejar claro que todas las opciones que forman un módulo suelen estar relacionadas entre sí, lo que requiere una programación estructurada, utilizando si es posible clases para diferenciar las distintas funcionalidades de un módulo. Por lo tanto, he comenzado a programar el módulo de nuevo. A partir de ahora el módulo tendrá dos posibles finalidades:

  • Offline: será un módulo que los alumnos utilicen para compilar y ejecutar sus problemas de programación. No requiere la intervención del profesor. Estará siempre disponible para los alumnos, dentro de las fechas de apertura y cierre que indique el profesor.
  • Examen: el módulo estará orientando a una actividad que se podrá calificar. Los alumnos deberán subir sus archivos fuente como resultado final. Este trabajo será calificado por el profesor.
Centrándome en temas de programación: he utilizado POO para desarrollar el módulo, tengo una clase remoterunning_base y una clase remoterunning_uploadsingle para diferenciar la funcionalidad Offline y Examen. La clase remoterunning_uploadsingle hereda de la primera. Además he reformado la tabla inicial, he añadido permisos con el archivo access.php, etc.

En próximos días comentaré más detenidamente los métodos de programación, ahora a seguir trabajando. La opción Offline funciona perfectamente, voy a seguir programando la segunda funcionalidad, muchísimo más complicada.

Saludos
Comentarios 9 ~ Comentar | Referencias (0)


 

Realizando funciones

Enlace permanente 11 de Junio, 2007, 19:06

Hola!
Durante estos días he seguido con la programación del módulo. He añadido más objetivos a esta entrega, como los siguientes:

  • Función source_route para los ficheros fuente: esta función devolverá en un parámetro las diferentes rutas de los ficheros fuente, según el lenguaje configurado en el módulo.
  • Función source_file: esta función creará el fichero fuente con la extensión adecuada al lenguaje utilizado en el módulo.
  • Actualizar el código de funciones predeterminadas del módulo: funciones como update_instance o delete_instance aparecen vacías y he de programarlas adecuadamente.
  • Botón upload: si he permitido la opción de subir un fichero, o el módulo está enfocado como examen, he de incluir un botón que suba archivos de los usuarios y los reciba el profesor adecuadamente.
  • Email al profesor: he de configurar esta opción correctamente.
También he estado trabajando con los objetivos del anterior artículo:

Ya he eliminado las rutas del estilo D:\appservmoodle... por sus equivalentes $CFG->dirroot."moodle...". También he creado la función source_route que devuelve las rutas de los ficheros fuente, según el lenguaje utilizado en el módulo, ya que tendrán distinta extensión:

function REMOTERUNNING_source_route($language,&$route) {
    global $CFG;
           
    switch ($language) {
          case 0: $route = $CFG->dirroot."modRemoteRunning\file.c";
                  break;
          case 1: $route = $CFG->dirroot."mod\RemoteRunning\file.cpp";
                          break;
          case 2: $route = $CFG->dirroot."mod\RemoteRunning\file.java";
                  break;
          case 3: $route = $CFG->dirroot."mod\RemoteRunning\file.ada";
                  break;
          case 4: $route = $CFG->dirroot."mod\RemoteRunning\file.f";
                  break;                                     
          case 5: $route = $CFG->dirroot."mod\RemoteRunning\file.c";
                  break;
              }
    }

En cuanto a las variables del formulario, ya se recogen todas correctamente para su posterior tratamiento. He tenido que modificar la tabla del módulo, quedando de la siguiente manera:

CREATE TABLE `prefix_REMOTERUNNING` (
  `id` int(10) unsigned NOT NULL auto_increment,
  `course` int(10) unsigned NOT NULL default '0',
  `name` varchar(255) NOT NULL default '',
  `description` text NOT NULL default '',
  `timedue` int(10) unsigned NOT NULL default '0',
  `timeavailable` int(10) unsigned NOT NULL default '0',
  `language` tinyint(1) unsigned NOT NULL default '0',
  `exam` tinyint(1) unsigned NOT NULL default '0',
  `grade` int(10) NOT NULL default '0',
  `timelimit` int(10) NOT NULL default '0',
  `upload` tinyint(2) unsigned NOT NULL default '0',
  `resubmit` tinyint(2) unsigned NOT NULL default '0',
  `emailteachers` tinyint(2) unsigned NOT NULL default '0',
  `maxbytes` int(10) unsigned NOT NULL default '100000',
  `timemodified` int(10) unsigned NOT NULL default '0',
  PRIMARY KEY  (`id`)
) COMMENT='Define REMOTERUNNING';

He creado la función reserve_words, que devolverá un mensaje de error en el caso de que se intente utilizar funciones del estilo exec(), system(), etc. Esta función revisará el código y suspenderá la compilación y ejecución, si se encuentran funciones potencialmente dañinas para el sistema. Esta función no está terminada, y que tengo que investigar el cógigo ADA, FORTRAN y JAVA para averiguar funciones de ejecución de programas:

function REMOTERUNNING_reserve_words($language,&$read,$text) {
       
    switch ($language) {
       
        case 0: $list = array    ("shell_exec","exec","system");
                        foreach ($list as $word) {
                            if (stristr($text,$word)!==false) {
                                $read = '<b>ERRORES:</b>';
                              $read .= '<BR>';
                  $read .= '<BR>';
                  $read .= $word;
                  $read .= ': ';
                    $read .= get_string('file_reserve_word','REMOTERUNNING');
                    return 0;
                  }
                }
                break;
        case 1: $list = array    ("shell_exec","exec","system");
                        foreach ($list as $word) {
                            if (stristr($text,$word)!==false) {
                                $read = '<b>ERRORES:</b>';
                              $read .= '<BR>';
                  $read .= '<BR>';
                  $read .= $word;
                  $read .= ': ';
                    $read .= get_string('file_reserve_word','REMOTERUNNING');
                    return 0;
                  }
                }
                        break;
        case 2: $list = array    ("exec","system");
                        foreach ($list as $word) {
                            if (stristr($text,$word)!==false) {
                                $read = '<b>ERRORES:</b>';
                              $read .= '<BR>';
                  $read .= '<BR>';
                  $read .= $word;
                  $read .= ': ';
                    $read .= get_string('file_reserve_word','REMOTERUNNING');
                    return 0;
                  }
                }
                break;
        case 3: $list = array    ("exec","system");
                        foreach ($list as $word) {
                            if (stristr($text,$word)!==false) {
                                $read = '<b>ERRORES:</b>';
                              $read .= '<BR>';
                  $read .= '<BR>';
                  $read .= $word;
                  $read .= ': ';
                    $read .= get_string('file_reserve_word','REMOTERUNNING');
                    return 0;
                  }
                }
                break;
        case 4: $list = array    ("exec","system");
                        foreach ($list as $word) {
                            if (stristr($text,$word)!==false) {
                                $read = '<b>ERRORES:</b>';
                              $read .= '<BR>';
                  $read .= '<BR>';
                  $read .= $word;
                  $read .= ': ';
                    $read .= get_string('file_reserve_word','REMOTERUNNING');
                    return 0;
                  }
                }
                break;                                     
        case 5: $list = array    ("shell_exec","exec","system");
                        foreach ($list as $word) {
                            if (stristr($text,$word)!==false) {
                                $read = '<b>ERRORES:</b>';
                              $read .= '<BR>';
                  $read .= '<BR>';
                  $read .= $word;
                  $read .= ': ';
                    $read .= get_string('file_reserve_word','REMOTERUNNING');
                    return 0;
                  }
                }
                break;
              }
        return 1;
            }

Mensajes de error. Ahora mismo estoy trabajando en este aspecto. La idea es que si se pulsa el botón de download del ejecutable o fichero fuente, y estos ficheros no existen, mostrar un error y volver a la vista del módulo. Por ahora consigo lanzar el error, pero al volver a la vista del módulo, se produce un error de seguridad que tengo que corregir.

Mañana más.

Bye
Comentarios 6 ~ Comentar | Referencias (0)


 

9º entrega

Enlace permanente 8 de Junio, 2007, 10:47

Después de 1 semana estudiando uno de los dos exámenes que me quedan para finalizar las asignaturas, continuo con el proyecto.

Se ha producido un fallo importante en la realización del proyecto, ya que la forma de ejecución de los programas desarrollados por el usuario en el módulo no es correcta. Si se ejecuta los programas desde una consola del SO, solo se visualizará en el servidor y no en el cliente, por lo tanto esta solución no es válida y tengo que pensar en otra forma de hacerlo.

He modificado la interfaz del módulo, para así tener más espacio para escribir el código. He añadido dos botones más, uno llamado compilar y otro llamado fuente. El primero realizará solo la compilación del código escrito por el usuario y el segundo permite descargar el código en un fichero.

También realizaré lo siguiente:

  • Mensajes de error: controlaré ciertos fallos que se puedan producir en el módulo, lanzando mensajes de error. Puede pasar que un usuario pinche el botón de descarga del programa y no haya ningún ejecutable creado.
  • Eliminar directorios: programaré adecuadamente las rutas de los ficheros con variables del tipo $dirroot y $wwwroot, eliminando la forma actual (D:\appserv\moodle...)
  • Recoger variables del formulario: modificaré la tabla del módulo para que recoja las variables de configuración.
  • Función palabras reservadas: mediante esta función se revisará el código para detectar palabras reservadas que se puedan utilizar para un uso fraudulento de la aplicación. Por ahora, este será el método para controlar el código malicioso.

Comentarios 4 ~ Comentar | Referencias (0)



Blog alojado en ZoomBlog.com

 

 

<<   Junio 2007  >>
LMMiJVSD
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28 29 30  

Categorías
General [41] Sindicar categoría