sábado, marzo 08, 2014

Aumentar Memoria en Tomcat7 y ubicacion para Genexus

  • Mmodificar el archivo CATALINA.BAT y asignar el siguiente valor 
  • set JAVA_OPTS=%JAVA_OPTS% -Xms512M -Xmx1024M -XX:PermSize=64m -XX:MaxPermSize=256m
  • Ejecutar startup.bat
  • Revisar si existe la asignación de memoria
Si el Genexus no recone automatica mente la ubicacion del Tomcat7, generalmente esto sucede cuando no realizamos la instalación, en lugar de ello se descomprime el archivo ZIP.

Debemos revisar que exista en el registro lo siguiente:

[HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation]
[HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat]
[HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat\6.0]
[HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat\7.0]
[HKEY_LOCAL_MACHINE\SOFTWARE\Apache Software Foundation\Tomcat\7.0\Tomcat7]
"InstallPath"="C:\\Tomcat7"
"Version"="7.0.50"

Si no existe cargar esos datos, hacer con REGEDIT y  registrar los datos arriba citados

Si requerimos hacerlo en linux ejecutar lo siguiente:

Linux:
JAVA_OPTS="$JAVA_OPTS -server -Xms256M -Xmx512M -XX:PermSize=64m -XX:MaxPermSize=128m"


Su significado:

-Xms256M => memoria heap inicial alocada

-Xmx512M => memoria heap máxima
-XX:PermSize=64m => perm gen inicial asignado
-XX:MaxPermSize=128m => perm gen máximo

domingo, marzo 02, 2014

Ejemplos de Facturacion electronica.

Tomado de: Registrar WS-SecurtyWS-Security DGI (Efactura) WebServices


Consuming DGI (Efactura) WebServices

The provided services from DGI called Efactura are webservices based on WS-Security. This specification is different from the standards
Webservice generated by GeneXus, so in order to communicate with them we must set up some configuration.
Note: These examples contains only an implementation for DGI Service "FACRECEPCIONSOBRE". 
Efactura News
Prerequisites
- Certificate
- RUC Number

.NET 

Note: GeneXus X Evolution 2 Upgrade 2 required
1. Install the certificate provided by DGI using mmc.exe from
Windows. Install it in "Personal" store on the Computer Account.
2. DGI signs the response with theirs certificate (DGI RUC PRUEBA CEDE). So in order to work property,
DGI certificate must be installed on the server.
In order to get this certificate go to https://www.efactura.dgi.gub.uy/ (Note2)
Install that certificate in Personal Store on computer account using mmc.exe.
This certificate will be used in order to authenticate with DGI web services.
3. Grant Certificate Permission to ASP.NET (or the user that is running the application): How to do it
4. Download and import this NET DGI XPZ WebService Sample that contains the
DGI WebService with the SDTs needed.
5. Set property Use Native Soap property = true to .NET Generator in order to use
WCF instead of GeneXus SOAP client. 6
6. Set the web.config as the following:
  • Replace: "RUC21XXXXXX" with the Serial Number of your certificate.
<system.serviceModel>
    <client>
      <endpoint address="https://efactura.dgi.gub.uy:6443/ePrueba/ws_eprueba" 
binding="customBinding" bindingConfiguration="dgiBinding" contract="GeneXus.Programs.ISdtWS_eFactura" 
name="GeneXus.Programs.SdtWS_eFacturaClient" behaviorConfiguration="ServiceBehavior">
        <identity>
          <dns value="DGI RUC PRUEBA CEDE" />
        </identity>
      </endpoint>
    </client>
    <behaviors>
      <endpointBehaviors>
        <behavior name="ServiceBehavior">
          <clientCredentials>    
            <clientCertificate findValue="RUCXXXXXX" x509FindType="FindBySubjectName" storeLocation="LocalMachine" storeName="My" />
            <serviceCertificate>
              <authentication certificateValidationMode="PeerOrChainTrust" />             
              <defaultCertificate findValue="DGI RUC PRUEBA CEDE" storeLocation="LocalMachine" x509FindType="FindBySubjectName" storeName="My" />
            </serviceCertificate>
          </clientCredentials>
          <protectionLevel level="Sign" />
          <!-- None, Sign, EncryptAndSign-->
        </behavior>
      </endpointBehaviors>
    </behaviors>
    <bindings>
     <customBinding>
        <binding name="dgiBinding">
          <security includeTimestamp="false" allowSerializedSigningTokenOnReply="true" 
authenticationMode="MutualCertificate" requireDerivedKeys="false" securityHeaderLayout="Lax" 
messageSecurityVersion="WSSecurity10WSTrustFebruary2005WSSecureConversationFebruary2005WSSecurityPolicy11BasicSecurityProfile10">
            <secureConversationBootstrap />
             <localClientSettings detectReplays="false"/>
          </security>
          <textMessageEncoding messageVersion="Soap11" />
          <httpsTransport />
        </binding>
      </customBinding>
    </bindings>
    <extensions>
      <behaviorExtensions>
        <add name="protectionLevel" type="GeneXus.Wcf.ProtectionLevelBehaviorElement, GxClasses, Version=10.1.0.0, 
Culture=neutral, PublicKeyToken=6f5bf81c27b6b8aa" />
      </behaviorExtensions>
    </extensions>
  </system.serviceModel>
7. WebPanel "Ejemplo_ServicioSobre" contains an example for calling DGI Service "Envio de mensaje con Sobre".
You need to replace the certificate that is being used within code: &CryptoUtils.FindCertificate("RUC21XXXXXX")
If there is warning certificate message's, it get a "Certficate with Subject = RUC21XXXXX not found" error.
In order to fix, there are two options
               - install a Certification Autorithy certificate (in order to fix the warning message) or
               - Looking for invalid certificates, it means, setting the parameter validonly = false . It would be replacing &CryptoUtils.FindCertificate("RUC21XXXXXX") for  &CryptoUtils.FindCertificate1("RUC21XXXXXX", storeName, storeLocation, false)
Note: DGI does not accept SOAP messages with empty element tags (example: <cantidad/>). XML Null Serialization property (SDT) property must be set to "No tag" in every SDT attribute. 
Note2: Another way to Get the DGI certificate is from the SOAP header in the response:
<wsse:BinarySecurityToken >MIIFvjCC.............</wsse:BinarySecurityToken>.
Copy the text inside tags BinarySecurityToken, then save as "cert.cer".

JAVA (tested Apache Tomcat 6 and 7)

Note: GeneXus X Evolution 1 Upgrade 6 required
1. Download JAVA_DGI_WS.zip  and extract to your hard drive.

2. DGIWS.xpz. Import into GeneXus.
3. Add "java_dgiWS_EOs.jar" to classpath in GeneXus.
3. Copy and merge all folders and files inside folder "webapp" to your Tomcat\WebApp directory.
4. Create your Java Key Store (JKS) from your Certificate:
For generating a .jks the following command can be executed:
keytool -v -importkeystore -srckeystore RUC2XXXXXXX.pfx -srcstoretype PKCS12 -destkeystore RUC2XXXXXXX.jks -deststoretype JKS. Refer to this link for more info.
(Temporary Limitation: Set the Java Key Store Password as the private key password). 
In order to obtain certifcate alias (needed for the next step), run the following command:
keytool -list -v -keystore RUC2XXXXXXX.jks
5. Download the Server certificate and import it into the Java cacerts. For example, suppose the downloaded certificate is dgi_ssl_cert.cer, a sample command is:
keytool -import -alias dgi_efactura_https -file "E:\DGI_HTTP_CERT.cer" -keystore "C:\Program Files\Java\jre6\lib\security\cacerts"             (default cacert password: changeit)
Check this article for further information. By default the WebService address is https://efactura.dgi.gub.uy:6443/ePrueba/ws_eprueba, check the ServicioSobre WebPanel reference:
&DGIWSWrapper.Address = "https://efactura.dgi.gub.uy:6443/ePrueba/ws_eprueba"
6. Open "ServicioSobre" to see how the DGI WebService is being called. You will need to edit the following code in order to specify the certificate information:
Sub 'SetConfigurationOptions'

&keyStoreFile = "C:\\RUC2XXXXXXX.jks"
&keyStorePassword = "desarrollo" //Current Limitation: keystorepassword must be equal to private key password
&keyStoreType = "JKS"
&privateKeyAlias = "xx-xxxx-xx-xxx-xxxx-xxxxx"

//Setting Certificate information in order to sign XML
&xmlSignatureutil.keyStoreFile = &keyStoreFile
&xmlSignatureutil.keyStorePassword = &keyStorePassword
&xmlSignatureutil.keyStoreType = &keyStoreType
&xmlSignatureutil.privateKeyAlias = &privateKeyAlias
&xmlSignatureutil.privateKeyPassword = &keyStorePassword

//Setting Certificate information in order to sign the SOAP message
&DGIWSWrapper.keyStoreFile = &keyStoreFile
&DGIWSWrapper.keyStorePassword = &keyStorePassword
&DGIWSWrapper.keyStoreType = &keyStoreType
&DGIWSWrapper.privateKeyAlias = &privateKeyAlias
&DGIWSWrapper.privateKeyPassword = &keyStorePassword

Endsub
and make sure to change the RUCEmisor and associated information in the GenerateSDT subroutine.

Logging

By default, logging is placed in C:\Temp\log4j.log
Note: For production environment you should turn off logging by opening "java_dgiWS_EOs.jar" with Winrar and deleting "java_  log4j.properties".

Troubleshooting

Problem: ErrorDsc: "No se pudo inicializar el módulo Axis Rampart -Connection has been shutdown: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException:
PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target"
Solution1:  Check again the step 5, the server side certificate is not imported in the local truststore
or not referenced using the Java variables (javax.net.ssl.trustStorePassword and javax.net.ssl.trustStore).
Solution2:  Add the server certificate to the Java Runtime Environment used by the Application Server. Link

Registrar Certificado para factura electronica.

Pasos para Facturacion Electronica:

Aqui algunas experiencias:

Tomado de:Ejemplos de Facturacion Electronica registrar certificado

javax.net.ssl.SSLHandshakeException - Instalar certificados en la Maquina Virtual Java


Tuve este inconveniente con la aplicacion en la que trabajo, este es parte del trace y debajo esta la solucion:

AxisFault
faultCode: {http://schemas.xmlsoap.org/soap/envelope/}Server.userException
faultSubcode:
faultString: javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target
faultActor:
faultNode:
faultDetail:
{http://xml.apache.org/axis/}stackTrace:javax.net.ssl.SSLHandshakeException: sun.security.validator.ValidatorException: PKIX path building failed: sun.security.provider.certpath.SunCertPathBuilderException: unable to find valid certification path to requested target


Eventualmente cuando queremos acceder a un servicio web atraves de nuestra aplicacion Java, necesitemos instalar un certificado a nuestra maquina virtual, para ello primero necesitaremos bajar dicho certificado en nuestra pc y luego instalarlo en la JVM


Para guardar el el certificado en la pc

Acceder a traves de un IE al wsdl del web services, una vez abierto ir a
file-> properties -> General tab -> certificates ->details tab ->copy to file ->aparece un wizard y luego presionar next-> ahi seleccionar el formato DER encoded binary -> ponerle algun nombre significativo al certificado y luego finish

una vez que tengo el certificado en la pc, ahora que hago?
Yo luego de guardarlo en la pc, copie los certificados a un directorio cercano al root
una cosa asi c:\directorio

Luego de eso procederemos a instalar el certificado con el Keytool en el cacerts

Aqui esta el comando ejemplo para instalar el certificado

C:\Program Files\Java\jre6\lib\security>keytool -import -alias webc -file "C:\certificates\webc.cer"
-keystore "C:\Program Files\Java\jre6\lib\security\cacerts"

donde webc es el nombre significativo de este ejemplo pero puede ser el que cada uno quiera y webc.cer es el certificado que bajamos con el wsdl

una vez que le damos enter a ese comando se nos va a requerir la password del keystore, la cual por defecto es changeit

Enter keystore password: changeit
Owner: CN=ebosi.vzbi.com, OU=VBP Cert, O=Verizon Business, L=Boston, ST=MA, C=US
Issuer: CN=VBP Certificate Authority, OU=VBP CA, O=Verizon Business, L=Boston, ST=MA, C=US
Serial number: 49
Valid from: Mon Feb 22 17:03:19 GMT-03:00 2010 until: Tue May 22 17:03:19 GMT-03:00 2018
Certificate fingerprints:
MD5: CC:0B:73:44:67:74:85:06:F2:82:57:D9:BA:53:A1:C4
SHA1: A2:3E:2C:E9:EB:A8:71:14:2C:4E:D9:1D:7B:06:6B:DF:54:29:8F:F6
Trust this certificate? [no]: yes
Certificate was added to keystoreMe ha dado este error:

error de herramienta de claves: java.io.FileNotFoundException: C:\Program Files (x86)\Java\jre6\lib\security\cacerts (Acceso denegado)

Si alguien sabe como arreglarlo??
Gracias

  Hay que ejecutar el cmd como administrador para que no te de ese error

lunes, diciembre 23, 2013

Primeros pasos con PrimeFaces, Eclipse y Tomcat (Paso a paso)

Articulo Original: PrimeFaces y Eclipse







Que es PrimeFaces?

Se trata de una suite open source de componentes que extiende a JSF


  • Posee un gran set de componentes UI (HtmlEditor, Dialog, AutoComplete, Charts, DatePicker, DataTables, TreeComponent, etc).
  • Tecnología Ajax basada an la API Ajax JSF 2.0
  • Muy liviana
  • Solo un archivo jar
  • No se requiere configuración
  • No tiene dependencias (salvo por supuesto JSF runtime 2.0 o 2.1)
  • Soporta Ajax Push via websockets
  • Mobile UI kit que permite la creación de aplicaciones web para dispositivos mobiles
  • Soporta Skinning y posee más de 35 temas preconstruídos. Soporta el editor visial de temas.
  • Documentación mantenida por la comunidad muy actualizada.
  • Muchos más
Se puede descargar la documentación en formato pdf desde aquí.
Se puede ver una demo llamada showcase que abarca todos los componentes de la UI y mobile desde aquí, además showcase permite ver el código fuente necesario para cada uno de las demostraciones.

Dependencias opcionales:

Que haremos?

Vamos a crear un proyecto web dinámico utilizando Eclipse 4.3 Kepler con WTP en el cual habilitaremos JSF y PrimeFaces. El proyecto y el post no son muy pretenciosos, solo veremos como implementar algunos componentes para que quede la idea de la facilidad con la que se trabaja utilizando esta suite.
Prerequisitos:
  • Tener instalado JRE 1.6 o posterior. 
  • Eclipse 4.3 Kepler, el cual puede descargarse desde aquí. En la página que se mostrará hay que seleccionar el sistema operativo, la distribución, en nuestro caso "Eclipse IDE for Java EE Developers" y la plataforma (32 o 64 bits). Una vez descargado solo hay que descomprimir el archivo y se creará una carpeta llamada eclipse, solo debemos entrar en esa carpeta y ejecutar el comando eclipse
  • Apache Tomcat 7.0.35, que puede descargarse desde esta página: http://tomcat.apache.org/download-70.cgi#7.0.35, una vez allí navegamos hasta la sección "Binary Distributions" se seleccionamos la distribución para nuestro SO. Recomiendo (zip para Window$ o tar.gz para Linux) a fin de no hacer más compleja la instalación. Una vez descargado el archivo lo descomprimimos en un carpeta, vemos que dentro se creará otra carpeta llamada "apache-tomcat-7.0.35" a la cual llamaremos [TOMCAT_HOME]
  • JSF 2.1.17 que se puede descargar desde aquí. Una vez descargado el archivo lo copiamos en una carpeta cualquiera la que llamaremos [LIB_HOME]
  • PrimeFaces 3.5 que se puede descargar desde aquí. Una vez descargado el archivo lo copiamos en [LIB_HOME].

Creando el proyecto.

Una vez que iniciamos eclipse y determinamos cual es nuestro workspace (recomiendo crear uno nuevo en el caso de tener uno ya), presionamos Ctrl+N para acceder al asistente de creación de nuevo proyecto y seleccionamos "Dynamic Web Proyect" y presionamos "Next >"


Como nombre del proyecto colocamos "pf" y luego presionamos "New Runtime..."

Ahora configuraremos un Server Runtime, esto implica que le diremos a eclipse donde se encuentran los archivos componentes del server.

Seleccionamos "Apache Tomcat v7.0" y presionamos "Next >"
Ahora debemos indicar el [TOMCAT_HOME] y presionamos "Finish". 


Ahora nos encontramos en el asistente principal nuevamente, presionamos "Next >"


En la próxima pantalla solo presionamos "Next >"

En la última pantalla del asistente solo debemos marcar para que se genere el descriptor de despliegue web.xml y presionamos "Finish"

Para finalizar nos cambiamos a la perspectiva JEE
Habilitando JSF.
En la vista "Project Explorer" presionamos botón derecho sobre el proyecto "pf" y seleccionamos "Properties" y seleccionamos "Project Facets", luego chequeamos "JavaServer Faces" y presionamos el link "Further configuration required..."


En la siguiente pantalla presionar el icono del administrador de librerías.


Luego crear una nueva librería presionando el botón "New...", el nombre de la librería será "JSF" y presionamos "Ok"


Una ve definida la librería, la seleccionamos y presionamos el botón "Add External JARs...", debemos seleccionar ahora el path [LIB_HOME]/javax.faces-2.1.17.jar. Presionamos "OK"


Una vez en la pantalla principal del asistente, seleccionamos la librería y agregamos un patrón de mapeo que debe ser "*.xhtml"



Los mapeos deben quedar como se ve en la siguiente figura, para finalizar presionamos "OK" en esta pantalla y en la anterior.


Habilitar PrimeFaces

Esto es por demás sencillo, solo debemos arrastrar el archivo "javax.faces-2.1.17.jar" sobre la capeta WEB-INF/lib. 


Una vez que lo soltamos seleccionamos la opción "Link to files" como se ve en la siguiente imagen.
Creando una instancia del servidor

Nos resta solo un paso para tener un proyecto JSF/PrimeFaces funcionando en un servidor, esto es, la instancia del servidor. Para ello en la vista "Servers" presionamos el link "new server wizard"

En la primera pantalla seleccionamos "Tomcat v7.0 Server" y presionamos "Next >"


En la última pantalla del asistente debemos pasar nuestro proyecto "pf· de la lista "Available" a la lista "Configured" para que se publique sea publicado en esta instancia del servidor, presionamos "OK" y listo.
 La vista de "Servers" debe verse más o menos así:
Primeros pasos con PrimeFaces (La vista)

Bien, ya tenemos todo listo para trabajar con PrimeFaces, esta es la parte más corta de este post!
Vamos a crear un archivo llamado gauge.xhtml, para ello debemos seleccionar la carpeta "WebContent" y luego presionar Ctrl+N, navegamos a la categoría "General" y seleccionamos "File", presionamos "Next >" y en la siguiente pantalla colocamos "gauge.xhtml", chequeemos que "parent folder" sea: "pf/WebContent" como nombre del archivo y presionamos "Finish".

Una vez creado el archivo lo abrimos en el editor haciendo doble click en el. El código que debe contener es:


<html xmlns="http://www.w3c.org/1999/xhtml"
   xmlns:h="http://java.sun.com/jsf/html"
   xmlns:p="http://primefaces.org/ui">
<h:head>
</h:head>
<h:body>
   <h:form id="formGauge">
      <p:poll interval="2" update="gauge" />

      <p:meterGaugeChart id="gauge" value="#{gaugeBean.meterGaugeModel}"
         showTickLabels="false" labelHeightAdjust="110"
         intervalOuterRadius="130"
         seriesColors="66cc66, 93b75f, E7E658, cc6666"
         style="width:400px;height:250px" 
         title="Custom Options" label="km/h" />

   </h:form>
</h:body>
</html>

Diremos que el tag:

<html xmlns="http://www.w3c.org/1999/xhtml"
   xmlns:h="http://java.sun.com/jsf/html"
   xmlns:p="http://primefaces.org/ui">
Son las que permiten utilizar los tags JSF y PrimeFaces

El tag:
      <p:poll interval="2" update="gauge" />
Hará que se actualice el elemento id="gauge" cada 2 segundos.

El tag:

      <p:meterGaugeChart id="gauge" value="#{gaugeBean.meterGaugeModel}"
         showTickLabels="false" labelHeightAdjust="110"
         intervalOuterRadius="130"
         seriesColors="66cc66, 93b75f, E7E658, cc6666"
         style="width:400px;height:250px" 
         title="Gauge Personalizado" label="km/h" />

Crea un gauge customizado, se personalizan cosas como los colores para los rangos, el alto el ancho, etc. El atributo value="#{gaugeBean.meterGaugeModel}", es uno de los más importantes ya que define la fuente de datos para este gauge, en este caso un bean llamado gaugeBean tendrá un método llamado getMeterGaugeModel(), el cual se traduce en un atributo llamado meterGaugeModel.

Con lo anterior hemos creado la capa de presentación, ahora falta el modelo que aportará datos a la presentación, en otras palabras el gaugeBean.


Primeros pasos con PrimeFaces (El modelo)

Vamos a crear una nueva clase java, para ellos debemos seleccionar el proyecto "pf" y luego presionar Ctrl+N, navegamos a la categoría "Java" y seleccionamos "Class", presionamos "Next >" y en la siguiente pantalla colocamos los datos que se muestran en la siguiente figura y presionamos "Finish":


Package: ar.com.magm.web.primeface
Name: GaugeBean
Debe implementar la interface Seralizable


Abrimos la clase recién creada y agregamos el código que se muestra en negrita.

package ar.com.magm.web.primefaces;
import java.io.Serializable;

import java.util.ArrayList;
import java.util.List;
import org.primefaces.model.chart.MeterGaugeChartModel;

public class GaugeBean implements Serializable {

private MeterGaugeChartModel meterGaugeModel;

public MeterGaugeChartModel getMeterGaugeModel() {
meterGaugeModel.setValue(Math.random() * 220);
return meterGaugeModel;
}
public GaugeBean() {
createMeterGaugeModel();
}
private void createMeterGaugeModel() {
List<Number> intervals = new ArrayList<Number>() {
{
add(20);
add(50);
add(120);
add(220);
}
};
meterGaugeModel = new MeterGaugeChartModel(0, intervals);
}

}

El método más importante es:
public MeterGaugeChartModel getMeterGaugeModel() {
meterGaugeModel.setValue((Math.random() * 190) + 20);
return meterGaugeModel;
}

Simplemente define una valor al azar para el MeterGaugeChartModel y lo retorna, esta es la fuente de datos, el modelo ya fue creado cuando se crea instancia y se definen los rangos que son:
add(20);
add(50);
add(120);
add(220);


A estas alturas, ya tenemos los dos componentes necesarios, solo resta "decirle" a faces que este bean existe y como lo debe manejar. Para ello debemos hacer doble click en "faces-config.xml" que se encuentra en la carpeta "WEB-INF", una vez abierto el editor seleccionamos la pestaña "ManagedBean" y luego presionamos el botón "Add".
En la siguiente pantalla rellenar "Qualified class name" con ar.com.magm.web.primefaces.GaugeBean y presionar "Next >"
Por último nos aseguramos que el nombre del bean es gaugeBean, que es el que usamos en el tag y que el scope es application, esto nos asegura una sola instancia para toda la aplicación, luego presionamos "Finish".
Para finalizar presionamos Ctrl+Shift+S para guardar todos los cambios.
Probando la aplicación
Para probar nuestra aplicación debemos iniciar la instancia que maneja nuestro sitio web, para ellos vamos a la vista "Servers", seleccionamos la instancia que configuramos al principio y presionamos el botón start.
Apache Tomcat por defecto escucha en el puerto 8080, nuestro sitio tiene por nombre "pf", por ello debemos abrir nuestro navegador e ingresar la URL http://localhost:8080/pf/gauge.xhtml, luego podremos ver algomo lo que muestra la siguiente imagen, pero si nos detenemos veremos que el valor del gauge se actualiza de forma automática cada 2 segundos.


miércoles, octubre 16, 2013

Simplificando las URL en aplicaciones Java desarrolladas con GeneXus

Tomado de: Simplificando las URL en aplicaciones Java desarrolladas con GeneXus

En una aplicación GeneXus Java tradicional tenemos nuestras URL de la forma:
http://localhost:8080/<MiAppJavaEnvironment>/servlet/home
o
www.url.com/<MiAppJavaEnvironment>/servlet/home

Si lo llevamos a producción es deseable que la URL en el Servidor en producción quede de la forma:
www.url.com/home



Para esto tenemos varios detalles para hacer:
a) Quitar el nombre de la WebApp
Para esto podemos poner la aplicación en el ROOT del Tomcat (borrar o renombrar el ROOT y poner nuestra webapp allí). Esta es la manera mas sencilla, pero tiene como contra que el Server quedaría solo una aplicación central aunque generalmente los usamos de forma dedicada (por lo que es válido y optimo para la mayoría de los casos).
b) Quitar el “/servlet” de nuestro sitio.
Para esto utilizamos alguna herramienta de URL rewrite como por ejemplo Tuckey (recomendado)
c) Quitar el puerto (:8080) para utilizar el default de HTTP (el puerto 80)
Generalmente en producción tenemos un servidor Apache de proxy para que las peticiones al puerto 80 vayan a nuestro Tomcat en el 8080.

 Instalación de Tuckey
1) Bajar el Jar de http://tuckey.org/urlrewrite/
2) Incluirlo en el lib de la webapp, una forma sencilla de hacer esto y de paso que quede todo el conocimiento y dependencias del proyecto en la KB es subirlo como un objeto File a la KB.
3) Modificar el web.xml agregando esto arriba del servlet mappings

<filter>
    <filter-name>UrlRewriteFilter</filter-name>
    <filter-class>org.tuckey.web.filters.urlrewrite.UrlRewriteFilter</filter-class>
</filter>
<filter-mapping>
    <filter-name>UrlRewriteFilter</filter-name>
    <url-pattern>/*</url-pattern>
    <dispatcher>REQUEST</dispatcher>
    <dispatcher>FORWARD</dispatcher>
</filter-mapping>

 4) Crear y agregar el archivo urlrewrite.xml en el WEB-INF
5) Agregar las reglas pertinentes en dicho archivo, la que he usado yo:

<urlrewrite>
    <rule>
        <from>^/([a-z]+)$</from>
        <to>/servlet/$1</to>
    </rule>
</urlrewrite>

Con esto nos permite tener URL más fáciles de recordar, más entendibles y una aplicación que es fácilmente migrable a otra plataforma (.NET por ejemplo) dado que la URL no contiene rastros del lenguaje utilizado.

jueves, septiembre 19, 2013

Crear un Exe con VFP8 en Adelante.



*!* Para ejecutar el VFP8 portable.
foxcode.exe
MSVCR70.DLL
FOXCODE.FPT
FOXCODE.DBF
vfp8.exe
VFP8ESN.DLL

*!* Para ejecutar el exe de tu aplicación (RunTime) sin usar el VFP8
MSVCR70.DLL
vfp8r.dll
VFP8RENU.DLL

 -- VFP8 Runtime Files --
http://fox.wikis.com/wc.dll?Wiki VFP8RuntimeFiles


*-- Genero el PRG, PJX y EXE

BUILD PROJECT Ejemplo.pjx FROM Ejemplo.prg
BUILD EXE Ejemplo.EXE FROM Ejemplo.pjx 

martes, agosto 27, 2013

HTTPS: así funciona

Muchos de los sitios que visitamos diariamente están protegidos por HTTPS. Gmail, Twitter, Facebook o Google son sólo unos ejemplos. Nos dicen que es por nuestra seguridad pero, ¿cómo nos protege ese protocolo? ¿Qué ventajas tiene frente a HTTP normal? Y, lo más importante: ¿Cómo funciona?

Vamos a intentar dar respuesta a todas esas preguntas en este artículo, empezando por la más importante: ¿por qué necesitamos HTTPS?

Imagino que todos sabréis qué es HTTP, el protocolo que utilizan los navegadores para comunicarse con los servidores web y que te permite ver páginas web como esta. Funciona bien pero tiene un problema: la seguridad.

Con HTTP, cualquier dato se transmite en texto plano, sin cifrar. Es decir, que cualquiera que se conecte a tu red WiFi, o que tenga acceso a la comunicación entre tu ordenador y el servidor (tu ISP, por ejemplo) puede ver todos los datos que recibes y envías. Por ejemplo, podrían ver las contraseñas que usas para entrar en tu correo, o realizar operaciones adicionales cuando navegas por la web de tu banco.

¿Qué es HTTPS?

Hay que cifrar esos datos para evitar que nadie más pueda verlos. Para eso está el protocolo HTTPS (Hyper Text Transfer Protocol Secure). En sí mismo HTTPS no es más que HTTP normal sobre SSL/TLS. 

SSL/TLS (Secure Sockets Layer/Transmission Layer Security) son dos protocolos para enviar paquetes cifrados a través de Internet, siendo el último el más moderno. Sirven igual para HTTP que para cualquier otro protocolo de comunicación, aunque en este artículo veremos únicamente su aplicación en HTTPS.

¿Cómo se establece una conexión segura?

Como bien sabéis, para cifrar datos se necesita una clave. Esa clave tendrá que saberla tanto el navegador como el servidor para poder comunicarse. El primer problema aparece rápidamente: ¿cómo compartimos una clave de forma segura (sin que nadie más pueda saberla)? Está claro que la clave tiene que ser única para cada conexión, por lo que no puede venir preconfigurada en los ordenadores. 

Aquí entra en juego una de las maravillas de la criptografía moderna: un sistema de clave pública/clave privada, cifrado asimétrico que ya nos explicaron en Genbeta Dev.

La pre-clave se genera en el navegador, y se comparte con el servidor usando criptografía asimétrica

Las claves pública y privada son un par de números relacionados de una forma especial, de tal forma que un mensaje cifrado con una clave sólo puede ser cifrado con su par correspondiente. Por ejemplo, si quiero enviar un mensaje a un servidor, lo cifro con su clave pública para que sólo se pueda descifrar con su clave privada.

Y precisamente este es el primer paso esencial de una conexión HTTPS. Después de haber acordado detalles técnicos entre navegador y servidor (versión del protocolo, algoritmos de cifrado asimétrico y simétrico que se usarán…), el navegador cifra una preclave generada en el momento con la clave pública del servidor al que nos queremos conectar. Eso se envía al servidor, que descifra la preclave con su clave privada. 

Tanto el servidor como el navegador aplicarán un cierto algoritmo a la preclave y obtendrán la misma clave de cifrado. De esta forma hemos superado el primer (y mayor) problema que teníamos: intercambiar la clave. A partir de entonces, simplemente se cifran y descifran los datos con esa clave. 

Como nadie más sabe esa clave, nuestras comunicaciones serán seguras y nadie podrá verlas (siempre y cuando el algoritmo de cifrado simétrico sea seguro, claro).

Alguno se preguntará por qué intercambiar una clave y no cifrar directamente los datos usando cifrado asimétrico. La principal razón es que el cifrado simétrico es muchísimo más rápido que el asimétrico, e intercambiar la clave no resulta un problema que haya que sortear.

¿Qué datos protege HTTPS?

La pregunta obvia es saber qué datos se protegen cuando usamos una conexión HTTPS. Como está basado en SSL/TLS, que funciona en la capa más baja de comunicación, se cifran todos los datos de HTTP. Esto es, no sólo la página web sino también la URL completa, los parámetros enviados, las cookies… Lo único que se queda al descubierto son los datos del paquete TCP: el servidor y el puerto al que nos conectamos. 

HTTPS sólo deja al descubierto el servidor y puerto al que nos conectamos.
Por lo tanto, HTTPS no sólo impide que alguien vea las páginas web que estamos visitando. También impide que puedan conocer las URLs por las que nos movemos, los parámetros que enviamos al servidor (por ejemplo, los usuarios y contraseñas se envían como parámetros POST normalmente) o las cookies que enviamos y recibimos (alguien con acceso a estas cookies podría robar nuestra sesión, como demostraba la herramienta Firesheep).

¿Cómo sé qué no me estoy comunicado con un impostor?



Hay un problema adicional en la comunicación por Internet. Pongamos que quiero navegar a Genbeta.com. ¿Cómo sé que me estoy comunicando con el servidor de Genbeta y no con un servidor falso que se está haciendo pasar por Genbeta (lo que se conoce como un ataque man-in-the-middle)?

Por lo tanto, hay que autenticar los servidores. No sirve de nada tener los datos cifrados si no nos aseguramos de que nos estamos conectando al servidor correcto. Para eso están los certificados SSL, que contienen la clave pública y los nombres de dominio en los que se pueden usar. 

Las CA (terceros de confianza) nos aseguran que el certificado es válido y que el servidor es quien dice ser.

El certificado SSL por sí sólo no sirve para nada. Cualquier atacante podría falsear uno y no te darías cuenta. Ahí entran en juego las CA, o Certificate Authority, las entidades emisoras de certificados SSL firmados, que sólo dan certificados sobre un dominio a su propietario. No podría, por ejemplo, ir cualquiera y pedir un dominio para google.com. Además, las firmas aseguran que el contenido del certificado no ha variado. No voy a extenderme viendo cómo es este proceso, ya lo vimos en un artículo anterior.

En resumen, una firma de una CA nos asegura que el servidor es quien dice ser. Por supuesto, hay que verificar esa firma para asegurarse de que es real. Para ello, el navegador busca el certificado en su almacén (en realidad es una anillo de confianza, algo más complejo) y verifica la firma. Si no es válida o no encuentra el certificado, te mostrará un aviso de que no puede autenticar la conexión al servidor.

Precisamente esto último ocurría hace un tiempo con Firefox (y otros navegadores, creo), cuando intentabas conectarte a servidores seguros de la administración española. Los certificados de esos servidores estaban firmados por la FNMT, pero Firefox no tenía en su almacén los certificados de la FNMT. Por esto mismo no podía asegurar que el certificado fuese válido y avisaba al usuario.

¿Qué debilidades tiene HTTPS?

El punto más débil de HTTPS son los certificados. Si, por ejemplo, alguien roba el certificado (con la clave privada) de Google, podría crear un servidor falso sin que hubiese forma de distinguirlo de uno legítimo. 

Un problema más grande puede ocurrir si se filtra la clave privada de una CA. Un atacante podría crear y firmar certificados válidos para cualquier dominio sin que nadie se lo impidiese, y por lo tanto engañar a los usuarios para que se conectasen a servidores falsos. 

Por suerte, todos los navegadores tienen un mecanismo para revocar certificados. Cuando se compromete un certificado, se pone su huella digital del certificado en una lista. El navegador se descarga esa lista y dejará de dar por válido cualquier certificado que aparezca ahí. El único problema está en que los navegadores no siempre aprovechan bien esas listas, pero el mecanismo está ahí.

Con esto, ya hemos acabado nuestra entrega de la serie “Así funciona…” sobre HTTPS. Podréis imaginar, especialmente los más legos en la materia, que hay cosas que he pasado por alto y otras que se han simplificado para hacer más fácil la lectura. Como siempre, intentaremos resolver las dudas y críticas que tengáis en los comentarios.

Tomado de: Articulo Original