El mecanismo de autenticación de los servicios web es un poco raro, así que dejenos darle un ejemplo de como haríamos para llamar un servicio que cree un usuario en Chamilo desde otra aplicación en PHP... luego explicaremos las distintas partes.
Al inicio, hemos formado una URL para acceder al WSDL. La mayoría de los archivos en main/webservices/ (casi todos) pueden ser llamados con un sufijo “?wsdl” para mostrar el WSDL (la presentación estructurada de las funciones disponibles). Esto debería ser suficiente para que cualquier cliente SOAP sepa qué funciones están disponibles para una llamada.
Luego hemos buscado una IP como el contenido del script testip.php. Este script está ahí específicamente para ayudarnos a formar la llave secreta: necesitamos mostrar al servidor que sabemos desde qué IP estamos llamando. Usando file_get_contents(), podemos obtener esta información directamente dentro de una variable.
Luego definimos una clave ($key)… Esta solamente la podemos obtener a través de un acceso directo al servidor web. Actua como una clave compartida (“shared key”) entre los dos servidores. Tenemos que abrir el archivo app/config/configuration.php, buscar la línea con $_configuration['security_key'], y luego copiar su valor dentro de nuestro script para formar nuestra clave secreta final. Esta es la que mandaremos al servicio web.
Finalmente, hemos preparado el array $params y llamado el servicio WSCreateUserPasswordCrypted(). Este servicio es una versión especial de WSCreateUser() que solo funciona si usamos el mismo método de cifrado de contraseñas de ambos lados (se tiene que mencionar en el parámetro encrypt_method que por ahora solo acepta 'md5' y 'sha1').
El parámetro original_user_id_name es lo que permite hacer el enlace entre Chamilo y nuestro servicio externo. Basta con darle un nombre constante que represente nuestro sistema y el hecho que se trata de un ID de usuario (por ejemplo joomla_uid sería un buen nombre para una conexión con un sistema Joomla, si es que este es el único sistema Joomla con el cual lo conectamos).Luego podemos darle el valor del ID del usuario en nuestro sistema externo dentro del parámetro original_user_id_value. Con este par de valores, podrá volver a editar o borrar cualquier usuario anteriormente creado via el servicio web : Chamilo mantendrá una relación entre el mismo y su sistema externo gracias al almacenamiento de estos datos.
La misma lógica funciona con los cursos y las sesiones: mantenemos, dentro de la base de datos de Chamilo, el dato del ID externo de esta entidad.
Algunos de los otros métodos disponiblies, con una explicación corta en cada caso:
Crea usuarios por paquetes. Se espera una contraseña sin cifrado (lo cual es aceptable sobre HTTPS pero noen otros casos).
Crea solo un usuario.
Crea usuarios tomando en cuenta que sus contraseñas podrían ser cifradas ya. Este método espera los parámetros siguientes :
encrypt_method puede ser md5 o sha1 o none en el caso de pasarlo en claro.
Crea un solo usuario tomando en cuenta que su contraseña podría estar cifrada
Edita las credenciales de un usuario (username + password)
Edita varios usuarios en paquete
Edita un solo usuario
Edita usuarios, enviando contraseñas cifradas
Edita unu solo usuario, enviando contraseñas cifradas.
Ojo : aunque muy discreto, hay un gran problema en Chamilo LMS 1.9.* ya que WSCreateUserPasswordCrypted espera el nombre de usuario en forma de un campo « loginname », cuando WSEditUserPasswordCrypted espera el nombre de usuario bajo un campo llamado « username ». Asegúrese que no se deje engañar por este, ya que podría tomarle mucho tiempo.
Borra usuarios por paquetes
Desactiva usuarios por paquetes
Activa usuarios por paquetes
Crea un curso
Crea un curso dando solo un título (en este caso el código del curso se generará automáticamente, lo cual puede ser un inconveniente en casos de estructuración específica)
Edita un curso existente
Obtiene la descripción de un curso existente
Edita una descripción de curso
Borra un curso
Crea una sesión. Este método espera los siguientes parámetros :
Edita una (o más) sesiones existentes basado en el campo original_session_id_value. Este método espera los siguientes parámetros :
Borra una sesión
Inscribe un usuario en un curso
Inscribe un usuario en un curso
Obtiene información sobre un usuario en base a su ID externo
Obtiene información sobre un usuario en base a su nombre de usuario (login)
Desinscribe un usuario de un curso
NOTA: por favor cuide los errores de teclado aquí: el servicio se llama equivocadamente « suscribe » en vez de « subscribe ». Por razones de compatibilidad ascendiente, lo hemos dejado así, pero no se equivoque: tiene que digitarlo en un inglés incorrecto para que funcione! Inscribe un usuario (alumno) en una sesión. Este método espera los siguientes parámetros :
Desinscribe un usuario de una sesión
NOTA : Ver nota sobre WSSuscribeUsersToSession arriba
Desinscribe varios usuarios de una sesión, por paquetes
NOTA : Ver nota sobre WSSuscribeUsersToSession arriba
Inscribe varios usuarios a una sesión por paquetes. Este método espera los parámetros siguientes:
NOTA : Ver nota en WSSuscribeUsersToSession
Elimina un curso de una sesión
Obtiene una lista de cursos disponibles en la plataforma
Actualiza la llave API de un usuario
Recupera una lista de las sesiones disponibles en la plataforma
Si se sumerge un poco en este tema, encontrará que hemos lanzado el desarrollo de distintos tipos de servicios web en SOAP, pero también en REST y XML-RPC.
No obstante, la versión más activa y mantenida hasta la fecha es SOAP (por ninguna razón en particular) y se concentra principalmente en un archivo: main/webservices/registration.soap.php
No todos los scripts de servicios web en main/webservices/ lo respetan, pero registration.soap.php permite definir restricciones sobre la dirección IP que puede llamar a los servicios web que contiene (esto no ha sido probado con IPv6 todavía).
Esta funcionalidad es posible gracias al pedazo de código siguiente dentro de la función WSHelperVerifyKey()
Como lo habrá entendido, necesita crear un archivo llamado « webservice-auth-ip.conf.php » dentro de la misma carpeta que _registration.soap.php_y añadir una lista de las direcciones IP (o los rangos) dentro del archivo mismo. Solo las direcciones IP que correspondan a los rangos o las IP indicadas serán aceptadas.
Cuando se haga uso de este método, el algoritmo que vimos antes para construir una clave de seguridad deberá ser modificado, ya que dejaremos de necesitar una dirección IP dentro de la clave.
Para los portales en los cuales la seguridad es una preocupación mayor, es una buena idea de usar este método.
Una información básica sobre servicios web en Chamilo LMS puede encontrarse aquí : pero la información que se encuentra ahí podría no estar actualizada (aunque tampoco la de este manual) ya que los servicios tienden a aumentar en cantidad en el tiempo.
Obviamente, hacemos lo posible para mantener compatibilidad ascendiente, pero la fuente más confiable siempre será el código (documentado en sí), que puede encontrarse en la carpeta main/webservices/ de Chamilo.