Saltar al contenido

Programación

Php – White screens….

This is another interesting problem that baffles the novice PHP programmers.

We make a quick change, and upload the file to webserver, we access the webapge and your are presented with a blank white page, aka ‘white screen of death’. It does not even show any error message.

We end up thinking what happened, we refresh the webpage but usually nothing changes.

Why this happens?

This happens because your host has switched off error reporting(for good reasons). So whenever their is a fatal error in your PHP script, and you have error reporting turned off you are presented with white screen of death.

So how to remedy it?

Their are two ways to get out of this situation,

  1. Changes in php.ini file

If you can have access to php.ini file then change the display error property to On.

display_errors = On

Also make sure that error reporting property is at least set to

error_reporting  =  E_ALL & ~E_NOTICE & ~E_STRICT
  1. Changes in the file

In case where you don’t have access to php.ini file, you can set these property in PHP script itself. Simply add following at the very start of your PHP script

error_reporting(E_ALL);
ini_set('display_errors',TRUE);

If you are using some, open source package like Drupal, Joomla or WordPress then put these codes in the index.php file in the root directory, right at top.

It is also possible that even though you see a blank page, but when you view the source you see the whole html code. This happens when you might miss proper closing an html tag, like <script>,<object> etc.

Please note that white screen of death can also happen due to problems in your Internet connectivity, this usually remedies itself when you do a page refresh.

Servicios Web con Perl

  • admin 

El lenguaje Perl cuenta principalmente con dos módulos que pueden ser usados para crear servicios web de manera fácil y rápida, desde cero o reutilizando aplicaciones de Perl ya existentes.Éstos módulos son SOAP::Lite y WSDL::Generator. A continuación se explicarán cada uno de ellos y se mostrará un ejemplo de su uso.

Tabla de contenidos

SOAP::Lite

SOAP::Lite es un conjunto de módulos de Perl que proveen una interfaz simple y liviana para el protocolo SOAP, tanto en el lado cliente como en el del servidor. SOAP::Lite es actualmente el kit de desarrollo de web services para Perl más difundido y utilizado. Su página en SourceForge ha registrado más de 10,700 descargas en casi 2 años.

SOAP::Lite provee clases para implementar funcionalidades de un cliente SOAP, varios servidores, soporte a datos y muchas otras tareas. La siguiente es una lista resumida de sus características:

Soporte de Protocolos

  • Soporta las especificaciones SOAP 1.1 y SOAP 1.2.
  • Incluye XMLRPC::Lite, una implementación del protocolo XML-RPC en el lado del cliente y del servidor. Entre los protocolos de trasporte disponibles, están HTTP, SMTP, POP3 y TCP.
  • Soporta publicación y peticiones UDDI del lado del cliente, a través de un API.

Interoperabilidad

  • Se han realizado pruebas de interoperabilidad con diferentes implementaciones: Apache SOAP, Frontier, Microsoft SOAP, Microsoft .NET, DevelopMentor, XMethods, 4s4c, Phalanx, Kafka, SQLData, Lucin (en Java, Perl, C++, Python, VB, COM, XSLT).

Protocolos de Transporte

  • Provee implementaciones de servidores TCP con multiservidor “no-bloqueante”
  • Soporta transporte sobre Jabber, MQSeries y SMTP.
  • Provee compresión transparente para HTTP.
  • Soporta el protocolo HTTPS.
  • Provee soporte para proxy.
  • Provee implementaciones de servidor POP3.
  • Soporta M-POST y redirección HTTP.

Soporte para WSDL

  • Soporta el esquema WSDL con “stub” y acceso en tiempo de ejecución. Soporta descripciones de servicio por directivas y cortas (tModel).

Otras

  • Provee implementaciones de servidores CGI, daemon, mod_perl, Apache::Registry yFastCGI.
  • Incluye los módulos de Apache mod_soap y mod_xmlrpc, los cuales permiten crear servidores SOAP o XML-RPC con algunas líneas en los archivos .htaccess o httpd.conf.
  • Soporta el enlace dinámico y estático de clases y métodos.
  • Provee un intérprete de comandos para sesiones SOAP interactivas.
  • Incluye una gran cantidad de ejemplos.

WSDL::Generator

WSDL::Generator es un módulo de Perl para crear archivos de descripción de servicios (WSDL) automáticamente a partir de módulos de perl expuestos como servicios web. Éste módulo, desarrollado por Pierre Denis <pdenis@fotango.com>, es tal vez el único que se ha creado hasta ahora con ésta funcionalidad en el mundo de Perl. SOAP::Lite y WSDL::Generator en la Práctica

Ejemplo

A continuación, se muestra un ejemplo de la utilización del lenguaje Perl para exponer un servicio web sencillo. En la documentación de los módulos puede encontrarse una descripción extendida de todas las funcionalidades que poseen y cómo utilizarlas.

El siguiente es el código fuente de un módulo de Perl que implementa una clase llamada “Cafetera”, con un único método llamado “prepararCafe”, que recibe como parámetro el número de tasas y devuelve como resultado un mensaje indicando el número de tasas preparadas:

Código del archivo Cafetera.pm <perl>

#!/usr/bin/perl -w
# Servicio web de ejemplo
package Cafetera;
use strict;
# Este es el constructor
sub new{
 my $proto = shift;
 my $class = ref($proto) || $proto;
 my $tasas = 0;
 bless($tasas,$class);
}
sub prepararCafe{
 shift;
 my $tasas = shift;
 print STDERR "Llamado con el parámetro $tasas";
 return "Se prepararon ".$tasas." tasas";
}
1;

</perl> A continuación se muestra el uso del módulo SOAP::Lite para exponer el módulo Cafetera como un servicio web, usando el servidor tipo SOAP::Transport::HTTP::Daemon:

Código del archivo servidor.pl <perl>

#!/usr/bin/perl -w
# Servidor SOAP
use SOAP::Transport::HTTP;
use Cafetera;
#En el parámetro dispatch_to se especifica la ruta a los módulos disponibles
my $daemonio = SOAP::Transport::HTTP::Daemon
 -> new(LocalAddr => 'localhost', LocalPort => 8070)
 -> dispatch_to('/home/tesis/thewala/preparacion/P.5-IP/productos/servicio-en-perl','Cafetera')
;
print "La url del daemonio es:".$daemonio->url()." ";
$daemonio->handle();

</perl> Desde éste momento, cualquier aplicación puede empezar a consumir el servicio web, si sabe cómo invocarlo. A continuación se muestra un cliente del servicio hecho en Perl con SOAP::Lite:

Código del archivo cliente.pl <perl>

#!/usr/bin/perl -w
use strict;
use SOAP::Lite;
my $soap = SOAP::Lite
 ->uri('http://localhost:8070/Cafetera')
 ->proxy('http://localhost:8070/')
;
my $resultado= $soap->prepararCafe(5)->result;
print "Preparando cafe: ".$resultado." ";

</perl> Para que aplicaciones hechas en otros lenguajes o que no saben cómo invocar el servicio puedan acceder al mismo, se debe crear el archivo de descripción WSDL. A continuación se muestra el guión o “script” de perl que utiliza WSDL::Generator para crear el archivo WSDL:

Código del archivo generar-wsdl.pl <perl>

#!/usr/bin/perl -w
use WSDL::Generator;
my $init = {
 'schema_namesp' => 'http://localhost:8070/Cafetera.xsd',
 'services' => 'Cafetera',
 'service_name' => 'Cafetera',
 'target_namesp' => 'http://localhost:8070/Cafetera.wsdl',
 'documentation' => 'Servicio Web de Prueba',
 'location' => 'http://localhost:8070/Cafetera'
};
my $w = WSDL::Generator->new($init);
Cafetera->prepararCafe(5);
print $w->get(Cafetera);

</perl> La salida de este guión de Perl constituye el documento wsdl que debe ser publicado para que cualquiera pueda acceder al servicio Cafetera. La siguiente es la salida del guión, la cuál puede guardarse en el archivo Cafetera.wsdl:

Código del archivo Cafetera.wsdl <xml>

<?xml version="1.0"?>
<definitions
 name="Cafetera"
 xmlns:xsd="http://www.w3.org/2001/XMLSchema"
 xmlns:soap="http://schemas.xmlsoap.org/wsdl/soap/"
 targetNamespace="http://localhost:8070/Cafetera.wsdl"
 xmlns:tns="http://localhost:8070/Cafetera.wsdl"
 xmlns="http://schemas.xmlsoap.org/wsdl/"
 xmlns:xsdl="http://localhost:8070/Cafetera.xsd">
<types>
 <xsd:schema targetNamespace="http://localhost:8070/Cafetera.xsd">
  <xsd:element name="prepararCafeRequest" type="xsd:string" />
  <xsd:element name="prepararCafeResponse" type="xsd:string" />
 </xsd:schema>
</types>
<message name="prepararCafeRequest">
 <part name="prepararCafeRequestSoapMsg" element="xsdl:prepararCafeRequest"/>
</message>
<message name="prepararCafeResponse">
 <part name="prepararCafeResponseSoapMsg" element="xsdl:prepararCafeResponse"/>
</message>
<portType name="CafeteraCafeteraPortType">
 <operation name="prepararCafe">
  <input message="tns:prepararCafeRequest" />
  <output message="tns:prepararCafeResponse" />
 </operation>
</portType>
<binding name="CafeteraCafeteraBinding" type="tns:CafeteraCafeteraPortType">
 <soap:binding style="document" transport="http://schemas.xmlsoap.org/soap/http"/>
 <operation name="prepararCafe">
  <soap:operation style="document" soapAction=""/>
  <input>
   <soap:body use="literal"/>
  </input>
  <output>
   <soap:body use="literal"/>
  </output>
 </operation>
</binding>
<service name="Cafetera">
<documentation>
 Servicio Web de Prueba
</documentation>
<port name="CafeteraCafeteraPort" binding="tns:CafeteraCafeteraBinding">
 <soap:address location="http://localhost:8070/Cafetera"/>
</port>
</service>
</definitions>

</xml>

Referencias

 

Usar certificados de cliente de la FNMT en una Aplicación Web

Existe poquísima información al respecto en Internet, muchos posts de gente, mucha historieta pero nada concreto. Voy a intentar, por lo tanto, dar las instrucciones para configurar un servidor de internet (en mi caso IIS, aunque la configuración es similar para el resto) para poder pedir al usuario que utilice un certificado emitido por la FNMT.

Paso I: La Seguridad
Si no tenemos una conexión https con SSL, GAME OVER, fin de la partida. Es requisito indispensable comunicarnos con el cliente mediante una conexión cifrada para poder interactuar con los certificados. Pero, ¿cómo lo hacemos para conseguir un certificado?. En desarrollo podemos seguir los siguientes pasos (en producción necesitareis un certificado emitido por una CA Root reconocida):

Existen muchos sitios en internet donde se describe este proceso, os pongo esta url donde explican como generar nuestro propio certificado con OpenSSL:
http://www.locualo.net/programacion/activar-ssl-iis-certificado-digital-prueba/00000079.aspx

Paso II: La Teoría
Vamos a ver un poco de la teoría para saber cómo funciona el tema de los certificados. Una vez que sepamos como funciona, entenderemos los pasos a dar. El circuito de los certificados es el siguiente:

1. El cliente accede a la url https://…. (para la cual es necesario un certificado de cliente)
2. El servidor envía su certificado al cliente para establecer el canal seguro. El cliente debe confiar en la entidad que ha generado ese certificado y comprobar que es válido. En caso de no confiar aparecerá un mensaje en el explorador indicándonoslo (la mayoría de la gente no lo lee).
3. Una vez que el cliente ha confiado en el servidor, se establece el canal seguro.
4. El servidor tiene configurado que para el recurso que intenta ver el cliente es necesario que presente un certificado de cliente, emitido por una entidad certificadora en la que él confíe y además que está en la lista de los certificados admitidos para el recurso en cuestión.
5. El explorador del cliente recibe estas condiciones del servidor y muestra una ventana con los certificados instalados que cumplan los requisitos del servidor.
6. El usuario elige su certificado y éste es mandado al servidor.
7. El servidor comprueba la lista de revocación de certificados de la entidad que emitió el certificado para ver si sigue siendo válido.
8. En caso que el certificado sea válido, podremos acceder al recurso y en la sesióntendremos guardado el certificado para usarlo.

En la siguiente imagen os muestro el flujo:

Paso III: La Confianza
Como habéis podido observar, la clave del asunto es la confianza entre los diferentes elementos (cliente y servidor). Vamos a ver cómo configurar nuestro servidor para: 1) requerir el certificado del cliente y 2)confiar en la fnmt para que acepte sus certificados.

Para requerir el certificado del cliente iremos al «Administrador de Servicios de IIS», buscaremos el recurso, sitio web o directorio virtual que necesitará certificado y pulsamos en «Propiedades» del menú contextual. En la pestaña «Seguridad de Directorios» pulsamos sobre el botón «Modificar» de la parte inferior. Nos aparecerá la siguiente pantalla:

Marcaremos la opción «Requerir Canal Seguro» y «Requerir Certificados de Cliente». Pulsamos sobre Aceptar y hemos terminado. Ahora el IIS espera un certificado del cliente para acceder al recurso, sin embargo, todavía no le hemos dicho que debe confiar en la FNMT como entidad certificadora.

Para confiar en la FNMT, tendremos que abrir una consola mmc (Ejecutar–> mmc), Archivo–>Agregar o Quitar Complemento. En la pantalla que aparece pulsaremos de nuevo sobre Agregar y seleccionaremos el complemento «Certificados»:

Pulsamos sobre «Agregar», seleccionamos la opción «Mi Cuenta de usuario» y cerramos la pantalla de agregar complementos. En la consola mmc, expandimos «Entidades emisoras raíz de confianza–>Certificados» y buscamos a la FNMT:

En caso que no esté, tendremos que importarlo. Lo primero será conseguir la definición del certificado de la FNMT. La podéis conseguir desde aquí:

http://www.cert.fnmt.es/content/pages_std/certificados/FNMTClase2CA.cer

Guardamos el fichero .cer en nuestro servidor y en la consola mmc pulsamos con el botón derecho sobre «Certificados» y elegimos «Todas las tareas–>Importar». Saltará un asistente para importar un certificado, seleccionaremos el fichero que nos acabamos de descargar y siguiente hasta el final.

Una vez importado, veremos las propiedades del certificado y habilitaremos la opción»Autenticación del Cliente». De esta forma habilitamos a los certificados de la FNMT para que sirvan como certificados de cliente.

Con esto hemos dado nuestra confianza a la FNMT como CA Root, sin embargo, todavía no funciona porque tenemos que incluir a la FNMT como entidad válida para nuestro recurso, en la CTL (Certificate Trusted List). Para ello, volvemos a la consola del IIS y nos vamos a las propiedades del sitio web en el que esté el recurso del certificado. Seleccionamos la pestaña «Seguridad de Directorios» y pulsamos sobre el botón «Modificar» de la parte inferior. Aparecerá la pantalla siguiente:

En la parte inferior tenemos la lista de certificados de confianza, pulsamos sobre «Modificar» y en la lista que aparece, pulsamos sobre «Agregar desde el almacén» e incluimos el de la FNMT. Pulsamos «Siguiente» hasta el final y ya tenemos todo hecho.

Paso IV: Final
Ya tenemos nuestro entorno habilitado para utilizar certificados de cliente. En producción tendremos que tener un certificado emitido por una entidad reconocida, pero el resto es igual.

 

Firmar una llamada SOAP con C# y ASP.NET

En este artículo se va a explicar cómo firmar una llamada SOAP utilizando la extensión para servicios web WS 3.0 de Microsoft. Como siempre, lo primero es un poco de teoría y luego veremos cómo pasar esta teoría a la práctica.

1. Teoría
La idea es poder realizar una llamada a un servicio web externo (una administración, por ejemplo) asegurando que el contenido de la misma no ha sido manipulado en el camino. El ejemplo más claro es el de una aplicación web que se integra con la administración, por lo que tiene que firmar las peticiones con el certificado de la FNMT del cliente que en ese momento este usando la aplicación.

La idea es que nosotros seamos una especie de pasarela de certificados de nuestros clientes a los servicios web de la administración o de otro sitio. Para realizar esto tendremos que firmar las llamadas SOAP con el certificado usando el estándar XMLSignature.

2. ¿Cómo lo hacemos?
Para hacerlo, lo primero que tenemos que hacer es descargarnos las extensiones de Servicios Web de Microsoft (WSE 3.0) que podéis encontrar en la dirección:

http://www.microsoft.com/downloads/details.aspx?FamilyID=018a09fd-3a74-43c5-8ec1-8d789091255d&displaylang=en

Una vez instalado en nuestro equipo, tendremos una nueva opción en Visual Studio para el trabajo con las extensiones de Web Services.

¿Cómo funciona WSE 3.0?
El centro del tema este son las políticas y los filtros. Cuando realizamos una llamada a un servicio web, ésta es interceptada por una clase que define lo que hay que realizar con dicha llamada antes de que salga. Cuando recibimos una respuesta, la respuesta es interceptada igualmente, y lo mismo pasa cuando definimos los servicios web.

Donde nosotros vamos a trabajar es en la clase de políticas de seguridad, que será donde se firme la petición.

Paso 1: Habilitar nuestro web para WSE3.0
Lo primero es habilitar nuestro sitio web para que utilice WSE3.0. Al habilitarlo, las clases proxy que se creen estarán preparadas para las extensiones de WSE. Tendremos que crearnos un sitio web en el Visual Studio y en las propiedades del sitio web veremos cómo aparece una nueva opción «WSE Settings 3.0». Al pinchar se abre la ventana:

Marcamos la primera opción para habilitar las opciones del cliente. La segunda opción es para habilitar las opciones cuando nosotros somos el servicio web.

Paso 2: Agregar la referencia a WSE
Agregar una referencia a la librería Microsoft.Web.Services3 a nuestro proyecto.

Paso 3: Agregar la referencia web
Agregaremos la referencia web al servicio con el que nos queramos comunicar.

Paso 4: Crear la política de seguridad
Vamos a crear la clase que controla la entrada y salida de mensajes SOAP desde el cliente. Esta clase tiene que heredar de SecurityPolicyAssertion

La clase tiene cuatro métodos, uno para cada situación: salida/entrada para el cliente y salida/entrada para el servicio. A nosotros el que nos interesa es el de la salida para el cliente, el resto lo ponemos a null.

La sección de imports es la siguiente:

En el constructor le pasamos el certificado del cliente (luego veremos cómo llamamos a esta clase) para poder utilizarlo en el método de salida del cliente. En este método lo que hacemos es instanciar una nueva clase que hereda de SendSecurityFilter que es la que realmente firma la petición:

En esta clase lo que hacemos es obtener el token del certificado y añadirle la firma al mensaje SOAP, haciendo override del método SecureMessage. Con esto tenemos prácticamente hecho todo.

Paso 5: Realizar la llamada
Nos creamos una página aspx desde la que vamos a realizar la llamada. Lo primero será obtener el certificado del cliente (ver el artículo anterior), una vez obtenido tendremos que asociar la política que hemos definido con la llamada al servicio web:

En este caso, he creado un servicio web con un método llamado «CalculaSuma» el cual suma dos números que se le pasan. En un botón llamado «btnInvocar» de la página le asocio el código para llamar al servicio web. Lo que hacemos es instanciar la clase proxy que se creó al agregar la referencia web y le asociamos la política que hemos creado.

Al realizar la llamada, la política intercepta el mensaje de salida, ejecuta el método «SecureMessage()» y firma la petición. Podemos activar el modo Trace con el asistente de WSE y ver la salida para comprobar que se ha firmado la petición, incluyéndose un nuevo elemento en la llamada SOAP llamado .

3. Fin
Espero que os haya gustado y servido este post. No ha sido muy exhaustivo pero como punto de partida para la utilización de XMLSignature en SOAP puede ser bueno.