28 octubre 2015

Creación de documentos XML mediante oXML

El componente externo oXML hace fácil la gestión de documentos XML desde nuestras aplicaciones Omnis. Cada nodo es tratado como un objeto independiente, lo cual facilita su localización y edición. Para la creación de un documento XML será necesario componer un objeto Omnis con el elemento DOM como subtipo, al cual iremos añadiendo los diferentes elementos que lo compondrán, mediante los métodos disponibles al efecto en el objeto DOM construido.

 

Creación de un documento XML


Para crear un documento XML, primero deberemos crear un objeto “DOM document” (“external objects-≥DOM document”). Este será el objeto principal del documento, mediante el cual podremos crear, buscar, editar y eliminar cualquiera de los nodos de que conste nuestro documento.

 

Adición de un elemento


Un documento XML está compuesto de varios “elementos” (también considerados objetos para oXML). Cada elemento posee un nombre, pero también puede poseer otras propiedades asociadas (explicados más adelante), tales como atributos, texto y comentarios. Cada elemento puede a su vez contener otros (conocidos como hijos), creándose así una estructura de tipo árbol, asociada al documento XML.

Tanto éstos elementos, como todos los demás objetos, son creados por el “DOM document”, mediante su conjunto de métodos “$createXXX()”. Por ejemplo, el método siguiente nos devuelve un objeto-elemento “oRoot”, de nombre “Root”:
; oXML es de tipo “Object”, con “DOM document” como subtipo
; lError es de tipo “Character”
; oRoot es de tipo “Object”, con “DOM Types-≥DOM Element” como subtipo
; oObj es de tipo “Object”, sin subtipo
; oElement es de tipo “Object”, con “DOM Types-≥DOM Element” como subtipo
Do oXML.$createelement("Root",lError) returns oRoot

Una vez obtenido el objeto-elemento, deberá ser insertado en el documento. Esto, deberá hacerse desde el propio objeto-elemento, el cual (en nuestro caso) se convertirá en el elemento padre del documento. Para hacer esto los objetos-elemento disponen de los siguientes dos métodos:

  • $appendchild() …que inserta el elemento al final de su lista de hijos.
  • $insertbefore() …que inserta el elemento delante del indicado.

Puesto que aún no existen otros elementos, al crear el primero, deberemos utilizar el objeto “DOM document” como padre: esto creará lo que se conoce como elemento “Root” o elemento-raíz, el elemento-raíz es único, es decir sólo puede existir uno y todos los demás elementos son descendientes de este.
Do oXML.$appendchild(oRoot ,lError)
Do oXML.$createelement("Elemento1",lError) returns oObj
Do oRoot.$appendchild(oObj, lError)

Mediante el método expuesto anteriormente insertamos el elemento-raíz en el documento y a continuación, obtenemos un segundo elemento (de nombre “Elemento1”), que es retornado sobre oObj (oObj ha sido declarado como un objeto sin subtipo, ya que es definido al obtenerse el elemento). Después insertamos el elemento como hijo de “oRoot”.

 

Propiedades de los Elementos


A pesar de que en nuestro ejemplo, ahora disponemos de algunos elementos-objeto, éstos aún no contienen información. Un elemento-objeto puede tener asociadas varias propiedades. Todos ellas son añadidas como hijos del propio elemento, esta operación es llevada a acabo del mismo modo que se añaden elementos-hijos a sus primarios. Los cuales pueden ser insertados delante o detrás del propio elemento.

 

Adición de textos


Existen dos modos diferentes de incluir un texto, los cuales denominaremos como “analizado” y “no analizado”. El método mas habitual es el “analizado”, lo que significa que su “analizador XML” deberá evaluar el texto. Por ejemplo, que el texto “Manzanas & amp; Peras” esté equiparado al texto “Manzanas & Peras”. El uso del modo “no analizado” no llevará a cabo la evaluación del texto, lo que significa que sea expresado literalmente, en nuestro caso, “Manzanas & amp; Peras”, sin filtrado de sus elementos.
; para crear un texto “PARSED” o “analizado”
Do oXML.$createtextnode("Manzanas & Peras", lError) returns oObj

; para crear un texto “UNPARSED” o “no analizado”
Do oXML.$createcdatasection("Manzanas & Peras", lError) returns oObj

Lo anterior, obtendrá un nodo de tipo texto con su texto, que después deberemos agregar del modo siguiente:
Do oElement.$appendchild(oObj, lError)

Adición de atributos


Los atributos son añadidos de modo muy sencillo. Tan sólo se requiere un nombre y un valor y son asociados al elemento mediante el uso de su propio método “$setattribute()”, tal y como mostramos a continuación:
Do oElement.$setattribute('Color','rojo',lError)

Lo anterior agregará el atributo Color = "rojo" al elemento oElement. Para añadir otros atributos al mismo elemento tan sólo deberemos repetir el proceso. Los atributos también pueden ser añadidos mediante el método “oXML.$createattribute()”, pero, en éste caso el atributo será añadido como un hijo.

 

Adición de comentarios


Los comentarios no son procesados por los analizadores XML, sólo están presentes para mejorar la legibilidad del documento XML. Son creados del siguiente modo:
Do oXML.$createcomment(‘Nuestro comentario', lError) Returns oObj
Do oElement.$appendchild(oObj, lError)

Instrucciones de procesamiento


Las instrucciones de procesamiento, proporcionan al XML, el modo específico en que deberá gestionarse la información contenida en el texto del documento. Formados por una “etiqueta” y un valor, proporciona la información necesaria para cumplir con su objetivo. (por ejemplo. Etiqueta = “xml-stylesheet”, valor = “type=’text/xsl’ href=’template.xsl’”. Estos también son considerados objetos, por lo que, deberemos hacer uso de un método predefino para la obtención de éste tipo de objetos, en éste caso será “oXML.$createprocessinginstruction()”, después deberemos añadirlo como hijo de un elemento.

 

Entidades


Las entidades están declaradas en el propio objeto “DOM DocumentType”. oXML utiliza el nivel 2 del DOM, el cual no permite la edición o creación de objetos “DocumentType”. Por lo tanto, el componente oXML sólo permite la lectura de las entidades ya incluidas en el propio documento XML.

 

Generación del fichero XML


Una vez construido el documento DOM en Omnis con todos sus elementos, tendremos que guardarlo en un archivo con extensión “.xml”. Para ello, disponemos del método “$savefile()” del propio objeto DOM, su modo de uso es el siguiente:
Do oXML.$savefile("C:\MiCarpeta\MiXML.xml", lError, kFalse, kXMLFormatFull)

El último argumento del método “$savefile()” nos permite especificar el formato del archivo XML a grabar. Las opciones de formato permiten especificar si se desea o no, añadir retornos de carro y saltos de línea, eliminar espacios, etc. diferentes “analizadores” podrán requerir de  ajustes en el formato del archivo XML resultante.

Existen otros métodos ya definidos para el objeto DOM, que podrían resultarnos útiles, pero en éste artículo, sólo les hemos presentado los básicos y a su vez suficientes en la mayoría de los casos, también nos proporciona una idea sobre como hacer uso de estos otros.

En Aula Omnis, podrá encontrar para su libre descarga, la librería de ejemplo “XMLex.zip” que muestra los métodos utilizados en éste artículo.

21 octubre 2015

Uso del Servidor de Sincronización Omnis

El “Omnis Synchronization Server” hace posible que una base de datos SQLite localizada en un dispositivo remoto (mantenida mediante una solución jsClient) pueda ser sincronizada con cualquier base de datos compatible, situada en un servidor.

En éste artículo mostramos su funcionamiento, usando para ello la librería de demostración denominada “syncdemo” la cual podrá encontrar lista para su descarga en Aula Omnis. La librería ha sido optimizada para dispositivos móviles iOS, pero puede ser fácilmente adaptada para su uso en otras plataformas.

 

Requerimientos


Para realizar lo expuesto en éste artículo, necesitará disponer de Omnis Studio 6.1 o superior, con capacidad para activar la propiedad “$serverlessclient” de los “remote form”. Propiedad necesaria para poder construir aplicaciones móviles independientes.

 

Configuración del “Synchronization Server”


Para conectar el “Synchronization Server” a una base de datos, debemos en primer lugar, definir una sesión específica en el “SQL browser”. Nuestro ejemplo está preparado para su uso con una base de datos SQLite, a continuación mostramos como configurarla.

 

Configurando la sesión


Seleccione “SQL Browser” desde el “Studio Browser”, haga clic sobre el hipervínculo “Session Manager” y después sobre “New Session”. Construya  una nueva sesión con el nombre “SYNCDEMO” tal y como mostramos a continuación, para terminar pulse OK.

 

Configurando el “Synchronization Server”


Abra el “Synchronization Server” desde la opción de menú “Tools≥≥Add-Ons”. Desde la pestaña “CDB Config” seleccione la sesión construida anteriormente y denominada “SYNCDEMO”, a continuación pulse “Save Details”, seguido de “Connect”.



Desde la pestaña “Sync Groups” añada dos grupos con los nombres “group1” y “group2”. Ambos con la palabra “syncdemo” como contraseña (no incluya las comillas).



En la pestaña “CDB Tables” active “Sync” y “SSR” para la clave primaria “nat_ID” de la tabla “naturetable” y finalmente pulse “Save Changes”.



 

Probando la conexión


Si la conexión con SQLite ha tenido éxito, se habrá abierto la sesión “CDBSESS” sobre el “SQL Browser”, permitiendo el acceso a los datos de “syncdemo” y la posibilidad de probar el “remote form” “jsServer”, para ello, haga clic derecho sobre el “remote form” y seleccione la opción “Test Form”.




Tenga en cuenta, que para poder ver correctamente la información de la pestaña “Map View” deberá disponer de una “Google ApiKey” activa y fijada sobre la propiedad “$apikey” del control “map” situado en el “remote form” “jsServer”.

 

Configurando las conexiones desde los clientes


Para poder recibir conexiones desde los clientes, deberá previamente determinarse el puerto del servidor sobre el que Omnis estará a la escucha, para ello, haga clic sobre el hipervínculo “Prefs” y localice la preferencia “$serverport”.

Por último, será necesario crear la página HTML “jsClient.htm” que utilizará la aplicación cliente cuando esté en modo “on-line”. Para ello, haga clic sobre el “remote form” “jsClient” y seleccione “Test Form”, esto causará la creación automática del fichero “jsClient.htm” sobre la carpeta “html” (situada en el directorio raíz de instalación Omnis) además será abierta sobre el navegador web. Tenga en cuenta que éste “remote form” no es funcional en éste momento, puesto que no está siendo ejecutado sobre el dispositivo del cliente, sólo hacemos esto con la intención de que se generé la pagina “html” de forma automática, de modo que simplemente cierre el formulario.

 

Construcción de la aplicación cliente “JavaScript Wrapper App”


Para activar la capacidad de sincronización en un dispositivo móvil, deberemos configurar y compilar la aplicación utilizando el “wrapper” Omnis JavaScript, disponible desde la página web de TigerLogic.

Consulte la información sobre su configuración y uso, como aplicación independiente desde en ésta misma página web, su dirección es:  (http://www.tigerlogic.com/tigerlogic/omnis/documentation/wrappers.jsp):

Edite el “wrapper”, y modifique las entradas que mostramos a continuación del fichero de configuración “config.xml”, donde “99.99.99.99” es la dirección IP de su servidor de sincronización Omnis y “1234” el puerto especificado en ese mismo servidor (tal como se ha descrito anteriormente en éste mismo artículo), recuerde que deberá usarse el esquema del “wrapper” específico para SQLite, concretamente el denominado “OmnisJSWrapper_SQLite” .
≤SettingsOnlineMode≥0≤/SettingsOnlineMode≥
≤ServerOmnisWebUrl≥http://99.99.99.99:1234≤/ServerOmnisWebUrl≥
≤ServerOnlineFormName≥jschtml/jsClient.htm≤/ServerOnlineFormName≥
≤ServerOfflineFormName≥jsClient≤/ServerOfflineFormName≥
≤ServerOmnisServer≥≤/ServerOmnisServer≥
≤ServerOmnisPlugin≥≤/ServerOmnisPlugin≥
≤ServerAppScafName≥syncdemo≤ServerAppScafName≥

Conexión desde la “app” cliente, al servidor de sincronización


La primera vez que ejecutemos la aplicación o “wrapper”, nos aparecerá el mensaje “no such table: naturetable”. Lo cual significa, que la tabla aún no existe en el dispositivo cliente, ya que aún no se ha producido su sincronización con el servidor.

Use la pestaña “Settings” de la aplicación cliente, para indicar la dirección del servidor de sincronización, además del grupo y su contraseña para su identificación en el servidor de sincronización (tal como hemos visto anteriormente) y pulse “Save”.



Asegúrese de que la ventana “Synchronization Server” este abierta sobre el servidor para así poder observar las conexiones entrantes y a continuación, pulse el botón “Syncinit” del cliente, seguidamente observe las entradas que se producen en el registro de la sincronización del servidor.



Una vez finalizada la sincronización, sitúese en su dispositivo sobre la pestaña “Data” y pulse “refresh”, esto causará que los datos del dispositivo se sincronicen con los del servidor.


Ahora podremos agregar nuevos registros o editar los ya existentes en nuestra base de datos SQLite local, es decir la ubicada en el dispositivo y después sincronizarla con el servidor, para ello deberemos hacer clic sobre el botón “Sync”.


Si nos situamos sobre la pestaña “Cache” antes de pulsar el botón “sync” podremos ver las solicitudes pendientes de sincronizar, junto con la lista de tablas existentes en el dispositivo. La pulsación (en éste momento) del botón “Sync” actualizará la base de datos del servidor y borrará la memoria caché.



Si así lo desea esta pestaña, puede ser fácilmente ocultada editando el “remote form” denominado “jsClient”, para establecer el valor inicial de la variable “iShowCache” a kFalse.

14 octubre 2015

Uso de comandos HTTP con Omnis

Caso ejemplo


Queremos hacer uso de comandos HTTP, para obtener una imagen ubicada en algún lugar de Internet y guardarla sobre un control JPEG de nuestro propio “remote form”, como por ejemplo la localizada en la dirección de internet: http://www.tigerlogic.com/omnis/images/omnis_studio_box.png.

 

HTTP Request y HTTP Response


Antes de entrar en detalles sobre el uso de comandos HTTP con Omnis, echemos un vistazo a lo que ocurre cuando se solicita una imagen, (o cualquier otro dato) mediante HTTP. Si introducimos la URL de un archivo imagen, (como por ejemplo la indicada en el párrafo anterior) en un navegador ésta será mostrada sobre la ventana del navegador, pero, lo que realmente ha sucedido es que el navegador (como cliente) a enviado un “HTTP Request” al servidor web “www.tigerlogic.com” solicitándole el fichero “/omnis/images/omnis_ studio_box.png” (parte de la URL, denominada URI), como consecuencia de esto, el servidor envía de vuelta un “HTTP Response” al navegador, que contiene, (entre otras cosas) el fichero solicitado. El formato de los paquetes de datos transferidos obedecen al protocolo estándar definido en el RFC 2616, consulte: www.faqs.org/rfcs/rfc2616.html

El “HTTP Request” está compuesto principalmente por una cabecera, que contiene los datos de identificación del cliente,  la información de lo solicitado por éste y su formato, mientras que el servidor responde con un “HTTP Response”, que a su vez consta de una cabecera y un cuerpo con la información requerida.

La cabecera de ambos es transferida en forma de texto ASCII estándar y por lo tanto puede ser “atrapada” mediante el uso de programas para el análisis de paquetes denominados “Sniffer’s”. Véase, por ejemplo: www.wireshark.org

Están compuestos por líneas individuales, cada una de ellas terminada con un retorno de carro (CR = Código ASCII 13) y un salto de línea (LF = Código ASCII 10). En cada línea, se asigna un valor a un campo, su formato es ≤nombre de campo≥":"≤valor≥. Entre la cabecera y el cuerpo hay una línea en blanco. De modo que, delante del cuerpo siempre encontraremos la cadena CR + LF + CR + LF.

 

¿Es Omnis un navegador?


Lo que podemos decir es que Omnis, soporta algunos comandos 4GL para la ejecución del ciclo “HTTP request/response”. Volviendo al caso planteado, podemos hacer uso de éstos comandos para obtener una imagen desde una ubicación remota. En primer lugar, Omnis deberá enviar una petición HTTP al servidor para recuperar o “conseguir” el archivo imagen. A continuación mostramos el código necesario: (“host” y “uri” son las variables locales de tipo “Character”, “socket” es de tipo “Long Integer”)

Calculate host as 'www.tigerlogic.com'
Calculate uri as '/omnis/images/omnis_studio_box.png'
HTTPGet (host,uri) Returns socket

Si la solicitud es aceptada, la variable “socket” contendrá un valor positivo, por su parte, Omnis habrá enviado lo siguiente:

GET /omnis/images/omnis_studio_box.png HTTP/1.1
Host: www.tigerlogic.com
Accept: */*
User-Agent: Raining Data - OMNIS


Si se desea definir parámetros adicionales para incluirlos en la cabecera de la solicitud o bien para nuestra propia versión de la URI utilizada por defecto, disponemos del comando “HTTPGet” el cual permite el uso de parámetros adicionales; en éste caso el código sería algo como lo siguiente:

Do cgiList.$define()
Do cgiList.$cols.$add(‘atributo’,kCharacter,kSimplechar,2000)
Do cgiList.$cols.$add(‘valor’,kCharacter,kSimplechar,2000)
Do cgiList.$add( ... )
Do headerList.$define()
Do headerList.$cols.$add(‘nombre’,kCharacter,kSimplechar,2000)
Do headerList.$cols.$add(‘valor’,kCharacter,kSimplechar,2000)
Do headerList.$add( ... )
HTTPGet (host,uri,cgiList,headerList) Returns socket

Si el “socket” es válido podremos recuperar datos del servidor, e ir guardándolos (en un primer momento) sobre (por ejemplo)  la variable “buffer” (definida como tipo “Character”):

HTTPRead (socket,buffer) Returns charCount

Los datos obtenidos tras el primer “HTTPRead” pueden no ser todos los esperados, por lo que, (como medida de precaución) es mejor crear un bucle (la variable “bufferPart” también es tipo “Character”). Así el código completo para leer una respuesta HTTP sería:

If socket>0
  Calculate buffer as ''
  Repeat
    Calculate bufferPart as ''
    HTTPRead (socket,bufferPart) Returns charCount
    Calculate buffer as con(buffer,bufferPart)
  Until (len(bufferPart)=0)|(charCount=0)
  HTTPClose (socket)
  ...(hacer algo)...
End If

Tras la obtención de todos los datos, será muy conveniente hacer uso del comando “HTTPClose” (socket) y después, comprobar que al inicio de la variable “buffer”; disponemos de algo como  lo siguiente:

HTTP/1.1 200 OK Server: Zeus/3.3
Date: Tue, 08 Dec 2007 12:34:57 GMT Content-Length: 4351
Content-Type: image/jpeg
Last-Modified: Thu, 01 Dec 2007 10:04:25 GMT
 

Tras la cabecera, vendrá una línea en blanco y luego los datos binarios.

Si se envía un “URI” inválido, como por ejemplo, solicitando el archivo “studio4_box.jpg” que no existe en el subdirectorio “/products/studio/” del servidor web, no se nos devolverá el número “2xx”, si no (generalmente) el correspondiente al error 404. De modo que, nuestra aplicación debería comprobar la presencia de este número sobre la primera línea devuelta, comprobando que su primer dígito sea igual a 2. Por ejemplo:

If not(mid(buffer,pos(' ',buffer)+1,1)='2')
  OK message Error {[uri] no localizado.}
  Quit method
End If


Ahora deberemos separar el cuerpo de su cabecera. Recuerde que todo lo que nos llega después de la línea en blanco, son los datos referenciados. Por lo tanto deberemos declarar las siguientes variables locales:

posEmptyLine (Long integer)
bufferStripped (Binary)
picFormat (Character)
 

y las variables-instancia:

iPicture (Binary)

finalmente deberemos añadir el siguiente código antes del comando “End If”:

Calculate posEmptyLine as pos(chr(kCr,kLf,kCr,kLf),buffer)
Calculate bufferStripped as mid(buffer,posEmptyLine+4,len(buffer))
Calculate picFormat as pictformat(bufferStripped)
Calculate iPicture as pictconvfrom(picFormat,bufferStripped)

Ahora podríamos asignar la variable IPicture a la propiedad “$dataname” de un control JPEG para así mostrar la imagen sobre nuestro “remote form”.

07 octubre 2015

RESTful con Omnis Studio (Parte 3 de 3)

En éste último artículo sobre el tema que nos ocupa, describimos cómo configurar un servidor web para que soporte autenticación para nuestros servicios web RESTfull construidos con Omnis Studio.

Sin duda queda de nuestra parte el construir un método de autenticación seguro para nuestra librerías Omnis. Pero cuando se utiliza un verdadero servidor Web (en lugar del servidor Tomcat), deberemos configurar su dirección URL para que soporte autenticación de tipo “basic” y/o “digest”. Por supuesto, también podemos hacer uso de https, y certificados de cliente para que las conexiones sean más seguras.

En las siguientes secciones, se han incluido algunas notas acerca de cómo configurar Tomcat, Apache Web Server y IIS para que soporten autenticación de tipo “basic” y/o “digest”. Configurar nuestro servidor de éste modo, significará que a Omnis sólo llegará la solicitud si el cliente se ha autenticado correctamente; en este caso, las cabeceras HTTP incluirán la “Authorization header”, con los detalles de la autenticación.

Omnis Studio incluye una nueva función denominada “parsehttpauth(auth)”, la cual analiza el valor (auth) del http “Authorization header” y devuelve una variable de tipo “row” con la información extraída. La primera columna denominada “named scheme” contiene la denominación del esquema (por ejemplo “basic”). El contenido del resto de sus columnas dependerá del tipo de esquema. A continuación mostramos algunos ejemplos:

Basic QWxhZGRpbjpvcGVuIHNlc2FtZQ==
  • La “row” devuelta tendrá las siguientes tres columnas:
    • scheme: basic 
    • username: Aladdin 
    • password: open sesame

Digest username="Mufasa",realm="testrealm@host.com",nonce="dcd98b7102dd2f0e8b11d0f600bfb0c093",uri="/dir/index.html",qop=auth,nc=00000001,cnonce="0a4f113b",response="6629fae49393a05397450978507c4ef1",opaque="5ccc069c403ebaf9f0171e9517f40e41"

  • La “row” devuelta tendrá las siguientes diez columnas:
    • scheme: digest 
    • username: Mufasa 
    • realm: testrealm@host.com
    • nonce: dcd98b7102dd2f0e8b11d0f600bfb0c093 
    • uri: /dir/index.html 
    • qop: auth 
    • nc: 00000001 
    • cnonce: 0a4f113b 
    • response: 6629fae49393a05397450978507c4ef1 
    • opaque: 5ccc069c403ebaf9f0171e9517f40e41

OAuth realm="Example",oauth_consumer_key="0685bd9184jfhq22", oauth_token="ad180jjd733klru7",oauth_signature_method="HMAC-SHA1", oauth_signature="wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D",oauth_timestamp="137131200", oauth_nonce="4572616e48616d6d65724c61686176",oauth_version="1.0"

  • La “row” devuelta tendrá las siguientes nueve columnas:
    • scheme: oauth 
    • realm: Example 
    • oauth_consumer_key: 0685bd9184jfhq22 
    • oauth_token: ad180jjd733klru7 
    • oauth_signature_method: HMAC-SHA1 
    • oauth_signature: wOJIO9A2W5mFwDgiDvZbTSMK%2FPY%3D 
    • oauth_timestamp: 137131200 
    • oauth_nonce: 4572616e48616d6d65724c61686176 
    • oauth_version: 1.0

Bearer 0b79bab50daca910b000d4f1a2b675d604257e42

  • La “row” devuelta tendrá las siguientes dos columnas:
    • scheme: bearer 
    • token: 0b79bab50daca910b000d4f1a2b675d604257e42
Para cualquier otro esquema:

  • La “row” devuelta tendrá las siguientes dos columnas:
    • scheme: denominación del esquema en minúsculas 
    • data: resto de la información de cabecera

Tomcat


Lo mostrado a continuación ha sido probado con Tomcat 7.0.42, ejecutado en Windows 8.1. Reinicie Tomcat después de cambiar los archivos de configuración.

Autenticación “Basic”


Configuración de usuarios: edite el fichero “conf/tomcat-users.xml”:

  • Añada perfiles y usuarios dentro de elementos ≤tomcat-users≥ por ejemplo:
≤role rolename="omnisrest"/≥
≤user username="bobm" password="bobm" roles="omnisrest"/≥

Edite el fichero “web.xml” del webapp omnisrestservlet (carpeta WEB-INF);

  • Añada lo siguiente después del elemento “servlet-mapping”:
≤security-constraint≥
≤web-resource-collection≥
≤web-resource-name≥All resources≤/web-resource-name≥
≤url-pattern≥/*≤/url-pattern≥
≤/web-resource-collection≥
≤auth-constraint≥
≤role-name≥omnisrest≤/role-name≥
≤/auth-constraint≥
≤user-data-constraint≥
≤!-- transport-guarantee can be CONFIDENTIAL, INTEGRAL, or NONE --≥
≤transport-guarantee≥NONE≤/transport-guarantee≥
≤/user-data-constraint≥
≤/security-constraint≥
≤login-config≥
≤auth-method≥BASIC≤/auth-method≥
≤realm-name≥omnisrest≤/realm-name≥
≤/login-config≥

Autenticación “Digest”


Igual que lo anterior, excepto que el “auth-method” debe ser “DIGEST”.

Probando localmente SSL


En el “conf/server.xml”:

Des-comente el conector SSL y modifíquelo, por algo como lo siguiente:

≤Connector port="8443" protocol="HTTP/1.1" SSLEnabled="true" maxThreads="150" scheme="https" secure="true" clientAuth="false" sslProtocol="TLS" keystoreFile="C:\apache-tomcat-7.0.42\mykeystore" keystorePass="xxxxxx"/≥

Creación de un certificado de servidor auto-firmado, para el almacén de claves tomcat:

  • Nota: Es necesario especificar un nombre y apellido para componer el localhost (a fin de permitir la realización de pruebas locales con OWEB como cliente)
  • "C:\Program Files (x86)\Java\jdk1.6.0_37\bin\keytool" -genkeypair -alias mycert -keyalg RSA -validity 10000 -keystore c:\apache-tomcat-7.0.42\mykeystore

Uso del cliente Omnis OWEB para pruebas:


Extraiga el certificado:

"C:\Program Files (x86)\Java\jdk1.6.0_37\bin\keytool" -exportcert -alias mycert -keystore c:\apache-tomcat-7.0.42\mykeystore -file my_root_cert

Impórtelo al “omnisTrustStore”:

cd ≤omnis path≥\secure\cacerts
"C:\Program Files (x86)\Java\jdk1.6.0_37\bin\keytool" -importcert -alias my_tomcat -keystore omnisTrustStore -file c:\apache-tomcat-7.0.42\my_root_cert

Ahora podrá usar con Tomcat, URLs como la siguiente: https://localhost:8443/omnisrestservlet/ws/5988/api/phase2/myapi/first

Nota: Para eliminar copias antiguas del certificado use:
"C:\Program Files (x86)\Java\jdk1.6.0_37\bin\keytool" -delete -alias my_tomcat -keystore omnisTrustStore

Apache Web Server

 

Autenticación “Basic”


Creación de usuario y contraseña:

  • c:\apache24\bin\htpasswd -c c:\apache24\test_passwords test
Nota: -c es opcional, sólo es requerido para la primera vez que se crea el fichero de contraseñas

Edite el fichero “httpd.conf”, la entrada “omnisrest” deberá ser como sigue:

≤Location /omnisrest≥
SetHandler omnisrest
AuthType Basic
AuthName "omnisrest"
AuthBasicProvider file
AuthUserFile c:\apache24\test_passwords
Require user test
≤/Location≥

Require” puede tener la forma, “Require user...”, “Require valid-user” o “Require group...”, consulte la documentación en línea de Apache, para más información.

Autenticación “Digest”


Creación de usuario y contraseña:

  • c:\apache24\bin\htdigest -c c:\apache24\test_digest_passwords omnisrest test
Nota: -c es opcional, sólo es requerido para la primera vez que se crea el fichero de contraseñas

Edite el fichero “httpd.conf”, la entrada “omnisrest” deberá ser como sigue

≤Location /omnisrest≥
SetHandler omnisrest
AuthType Digest
AuthName "omnisrest"
AuthDigestDomain /omnisrest/
AuthDigestProvider file
AuthUserFile c:\apache24\test_digest_passwords
Require valid-user
≤/Location≥

Des-comente la línea “LoadModule auth_digest_module modules/mod_auth_digest.so” del “httpd.conf”.

Require” puede tener la forma, “Require user...”, “Require valid-user” o “Require group...”, consulte la documentación en línea de Apache, para más información.

IIS


Autenticación “Basic”


IIS es bastante difícil de configurar (o al menos IIS Express que es el que hemos probado). En primer lugar, es necesario habilitar la autenticación “basic” y desactivar la autenticación “anonymous” en el archivo “AppServer\applicationhost.config” (que podremos encontrar bajo el directorio de instalación de IIS Express). Haga una búsqueda de la cadena “authentication” y modifique lo que sea pertinente.

Agregue el código siguiente al final del fichero “applicationhost.config”, justo después del elemento “location” principal:

≤location path="Default Web Site/cgi-bin/omnisrestisapi.dll"≥
≤system.webServer≥
≤security≥
≤authentication≥
≤basicAuthentication enabled="true" /≥
≤/authentication≥
≤/security≥
≤/system.webServer≥
≤/location≥

A continuación, puede utilizar el usuario y su contraseña, con URL’s protegidas - tuvimos que crear una nueva cuenta de usuario estándar para conseguir que esto funcionase.