FORO DE DISCUSIÓN


Proyecto para la digitalización de los Certificados de Origen de ALADI


Ingresar su comentario
Mensajes

08/21/07 15:14  - lcasaco

Para Carolina (AIERA).

Caro, copio/pego el mensaje que me enviara Sergio Otero, a propósito de tu consulta. Puedes responderle por aqui.
Saludos,
Luis

-----------------------------------------------------

Luis, no encuentro mi user/pass del foro....
(..) me parece que en este doc. http://foros.aladi.org/gtah/cod-ver2-15-06-06-ar.xls está la relación entre campos XML y campos de los formularios que responden algunas de las inquietudes de Carolina.
Lo podrías publicar por favor?
Un abrazo como siempre.
Sergio


08/21/07 10:14  - lcasaco

Pongo a consideración del GIF el siguiente mensaje que me envió Carolina Pereyra, de la AIERA.
Saludos,
Luis
----------------------------------

Estimado Luis,
Quería comentarle que luego de haber recibido el ejemplo de COD de Certicámara y revisar en profundidad toda la estructura nos surgieron algunas dudas conceptuales sobre el contenido del mismo y sobre cómo completar algunos campos.

Las dudas son las siguientes:

1) <Fecha_Declaracion_Exp>: ¿Se trata de la fecha de la Declaración Jurada?
2) <Nro_Registro_Fiscal>: Este campo se completa con el Nro de Registro de Aduana (Nro Importador-Exportador) o con el CUIT - Nro de Registro de AFIP (Ente recaudador fiscal argentino)
3) <Fecha_Inicial> y <Fecha_Final> ¿Es la vigencia de la Declaración Jurada?
4)Pregunta genérica: En cuanto a la obligatoriedad de los campos, ¿Los mismos se completan según la lista de Acuerdos que figura en la columna "Campo Contemplado en los formularios de los siguientes Certificados de origen" del documento de Especificación? Por ejemplo, los datos de los productores únicamente figuran para el TLC CE Nº 60, Argentina al no estar incluída en ese Tratado, no lo debe completar, no? Lo mismo aplica para otros campos como ser el Valor Regional.; <Otras instancias> DMI< Otras instancias> ; < Representante>.-
5) En cuanto al Consignatario:
<País_Con> y <Pais_Destino> pueden ser distintos?
6) Como se completa el campo <Cantidad_Hojas> en el tag Acuerdo.
7) Para las operaciones por cuenta y orden de un Tercer Operador, es posible que solo se completen los datos de la razón social y no el nro y fecha de la factura? porque actualmente muchas veces sucede que al momento de emitirse l Certificado de Origen el exportador no cuenta con dicha factura y la presenta más tarde. En ese caso los datos de la factura del Tercer operador quedarían en blanco.
8) <Fecha_Declaracion_Jurada> es lo mismo que <Fecha_Declaracion_Exp>?
9) Campo 54 Acuerdo acrónimo, ya está la lista de acrónimos, se puede sacar del sitio de ALADI?
10) En campo Observaciones - Insumos PAC- cual es la información básica exigida para este campo?

Por ahora esto es todo, aguardo sus comentarios.
Muchos saludos!
Carolina


03/13/07 09:01  - aluisio

Em 27/11/2006 postamos no forum uma dúvida, que provavelmente é pertinente, mas não recebemos qualquer comentário. Seria importante e útil para nós recebermos alguma observação sobre o tema, mesmo que negativa. Obrigado.


11/27/06 18:01  - aluisio

Saludos a todos.

Estamos analizando algunas situaciones con certificados de origen reales y la estructura del COD y nos surgió una duda. Conforme la estructura modelo combinada hasta hora, disponible en http://foros.aladi.org/gtah/doc-0-estructura-cod-modelo.xls, los campos 23 (Exportador:Fecha_Declaracion_Exp), 24 (Período que cubre: Fecha_Inicial) y 25 (Período que cubre: Fecha_Final), están en el inicio del documento, conectados al Exportador.

Sin embargo, un único certificado de origen puede contener diversos productos, y cada uno de esos productos está ligado a una declaración diferente, cada una con su propia fecha, habiendo por lo tanto diversas fechas diferentes de declaraciones.

De la forma actual, parece que es prevista sólo una declaración por certificado, pero en realidad pueden haber diversas declaraciones relacionadas a un certificado, una para cada producto.

Disponemos en nuestro servidor ejemplos para que quede más claro. Las direcciones son:
http://www.certificado.fiesp.com.br/COD/COD_V1_FIESP.xml

Si nuestro entendimiento estuviere correcto, gustaríamos de sugerir la mudanza de posición de los campos 23, 24 y 25 para que los mismos queden juntos con los corresponsales ítems de productos, tras el campo 66.


http://www.certificado.fiesp.com.br/cod/Sugestao_COD_V1_FIESP.xml


Quedamos a la espera de las consideraciones del forum.

Equipo FIESP/Brasil


09/28/06 17:08  - barance

Sergio, gracias a ti.

He hecho las pruebas de firma utilizando un CID chileno y el resultado ha sido positivo, el problema de ayer era fruto del cansancio personal (otros le llaman estupidez pasajera).
He probado en Windows XP con la ultima versión de Java y tanto en Explorer 6 como en Mozilla-Firefox 1.0.7 y el funcionamiento ha sido lento pero excelente.
Proximamente haré pruebas similares sobre Linux (Mandriva)y les informaré.


09/28/06 09:41  - sotero

Bernardino, olvide el por favor y el gracias!
Saludos
Sergio


09/28/06 09:37  - sotero

Bernardino, me podes enviar el cod.xml por email?
sotero@cajval.sba.com.ar


09/27/06 19:09  - barance

He probado el sistema de firma con un certificado chileno y no consigo que firme.
Tengo todo instalado, no me da ningún aviso de error...todo bien pero no firma.
¿Alguna idea de que puede ser?


09/27/06 17:39  - sotero

Buenas tardes, a pedido de Luis, repito lo que envie por email.
Para ayudar a los que no puedan acceder al Applet Demo de Firma XML ( http://www.cera.org.ar/ALADI/index.htm ),le agregué un boton de Ayuda que muestra una animación Flash sobre como funciona. Paciencia por favor, que anda un poquito lento.

Saludos cordiales,

Sergio


09/26/06 14:59  - julio

Buenos tardes:

Pertenezco a la parte de Desarrollo y Soporte de ALADI. Con respecto a la consulta de Ronnie sobre el Applet, hay que referirse la e-mail del 31/08/06 publicado en el foro por el usuario sotero.

En ese correo se refiere a los requisitos para la utilización del Applet. A continuación agrego los requisitos o advertencias:

"1) para usar el visualizador, tienen que usar Internet Explorer (no lo hice para Mozilla).
2) Tienen que tener Java habilitado en su browser e instalada una JVM (http://java.com/es/download/index.jsp)"

Si no se instaló el JVM al correr el applet da ciertos errores. Luego de haber instalado el JVM no me dió ningún tipo de error.

Saludos,

Ing. Julio C. Delgado Arce
Departamento de Información y Estadística (DIE)
Asociación Latinoamericana de Integración (ALADI)
Dirección: Cebollatí 1461 esq. Barrios Amorín
Teléfono: (598 2) 410 11 21 interno 117
E-mail: jdelgado@aladi.org


09/26/06 14:48  - lcasaco

Para los que han tenido problemas en visualizar el Applet que preparó Sergio, éste me envió un demo en flash como alternativa. Deben descompactar los archivos al mismo Dir y doble-click al archivo html. El demo lo pueden descargar de http://foros.aladi.org/gtah/appletfirma.zip


09/26/06 10:32  - lcasaco

Sergio, recibí este mensaje de Ronnie, el colega de la FIEMG. Le pedí que ingresara sus comentarios directamente en el foro. Respóndele por esta misma vía.
Saludos,
Luis
----------------------------------------
Estimado Luis,

Le comunico que yo no conseguí testear el applet de firma que desarrolló Sergio, aunque el COD.xml y el CID ya tengan sido bajados y el importación obtuve éxito.

Tendría que hacer algo mas? El visualizador contiene errores en la ventana.

Cordial Saludos,
Ronnie Pimentel
CIN-MG
FIEMG


09/13/06 15:38  - lcasaco

No sé si todos han "testeado" el applet que preparó Sergio, pero a juzgar por sus silencios....la verdad que no me queda claro. Por favor, es importante conocer sus opiniones.

A modo de información, les comento que por este lado se ha trabajado en un informe técnico que contempla no solo el listado de servicios que la ALADI estará ofreciendo en su rol en el Proyecto COD, sino también los requerimientos -técnicos, operativos y humanos- para lograrlo. Aunque en versión preliminar, este informe ha sido enviado a las representaciones permanentes de los países miembros de la ALADI y se esperan comentarios. El próximo paso es neta y puramente político, así que les informaré según se reciban los feedbacks.

Mientras tanto, y una vez que resolvamos el tema de la firma del COD.xml (algo en lo que Sergio, Enrique y Pablo han sido activos protagonistas, aunque también sé que Willman ha estado trabajando fuerte), debemos enfocarnos en el proceso de la validación del COD. (Esto último va dirigido a los colegas aduaneros)

Abrazos a todos,

Luis


09/05/06 13:36  - lcasaco

Estimados colegas:

Les comento que Sergio me informó que hizo una actualización de la planilla XSLT para la visualización del COD firmado.

Les recuerdo donde se publica el applet que preparó Sergio: http://www.cera.org.ar/ALADI/index.htm

Saludos,

Luis


09/01/06 09:53  - lcasaco

Estimados colegas:

Pongo a disposición del GIF el applet de firma que desarrolló Sergio, según lo acordado hasta el momento. Está en http://www.cera.org.ar/ALADI/index.htm.

El COD.xml y el CID (cera.p12) que necesitan para usarlo están compactados en el archivo "Probando applet - Ver 0.10", en la sección documental del foro COD. (URL: http://foros.aladi.org/gtah/test-signing-applet-010.zip).

Password: cera.

Gracias Sergio.

Saludos,
L.


08/31/06 17:33  - sotero

Les comentó que está publicado en http://www.cera.org.ar/ALADI/index.htm un applet que sirve para que se generen COD firmados, según el formato consensuado hasta acá. Es necesario contar con un CID y un COD.xml. Le envíe ambos a Luis para que los ponga a disposición de quien lo necesite.
Algunas advertencias :
1) para usar el visualizador, tienen que usar Internet Explorer (no lo hice para Mozilla).
2) Tienen que tener Java habilitado en su browser e instalada una JVM (http://java.com/es/download/index.jsp)
3) La plantilla XSL debe ser adaptada a algunos cambios (aun no tuve tiempo de terminarla, pero la idea sirve)
Saludos a todos,
Sergio


08/30/06 09:41  - lcasaco

Bajo el título "XML Signer ver 2.0.1", publico las últimas versiones de la clase EnvelopSigner.java, el COD.xml y el XML firmado que me enviara ayer Sergio, vía email. (click en http://foros.aladi.org/gtah/xml-signer-201.zip)
Adjunto su mensaje para conocimiento del GIF y espero las contribuciones de los demás colegas.
Saludos

Luis

--------------------------------------------------------------
Mensaje citado:

From: CV - Otero Blasco Sergio <sotero@cajval.sba.com.ar>; 29/08/2006 16:37
To: "'lcasaco@aladi.org'"; <lcasaco@aladi.org>;
cc: 'Enrique Almeida' <ealmeida@concepto.com.uy>;, CV - Daraio Roque <rdaraio@cajval.sba.com.ar>;
Subject: Novedades

Luis :

Aproveche un ratito que tuve y terminé la clase que firma según la última versión de Enrique. Te adjunto el COD.xml, el xmlFirmado.xml y la clase EnvelopeSigner.java que lo produce para ponerla a consideración general. Siempre aclaro, que esta hecha con fines didácticos, ya que firma el Expo y la EH en la misma ronda y con el mismo certificado, no le llega como parámetro el Nro. de COD, etc.
La finalidad es empujar el establecimiento del standard que vamos a usar, y la posibilidad de usar ese código de base para las aplicaciones que tengan las demas entidades del foro.
Si me haces el favor, podés publicar la novedad? Me estoy yendo temprano hoy, tengo el cumple del mas pequeño de los mios.
Un abrazo.

Sergio


08/28/06 15:24  - lcasaco

Estimados colegas:

Esto es un LLAMADO DE ATENCIÓN!

Aunque sé que todos están leyendo lo que se publica en este foro, son pocos los que lo utilizan ACTIVAMENTE y los tiempos se acortan. Se supone que para septiembre debemos tener un modelo del COD. Entonces, ¿qué dicen los demás técnicos de las EH y de las Aduanas Nacionales que permanencen tan callados? Espero comentarios.

Asi mismo, agradezco, públicamente, la dedicación y el liderago que han mostrado Enrique, Pablo y Sergio, en estas primeras semanas.

Saludos,

Luis


08/28/06 11:18  - lcasaco

Estimados colegas:

Se subió a la sección documental del foro COD el archivo correspondiente a la versión del XSD que nos enviara via email Pablo Icaza desde la Aduana de Chile. La publiqué con el título COD.xsd - ver 1.01 (http://foros.aladi.org/gtah/COD.xsd)

A propósito del foro GIF quiero recordarles que, con independencia de que utilicen el email para mandarse archivos adjuntos (la cual me parece una vía excelente):
(1) deben usar el foro para escribir sus comentarios, y así le damos participación del trabajo a todos los colegas del GT y;
(2) la lista de correos que han usado para enviarse los documentos es incompleta. En un par de minutos les estaré enviando una nueva lista, con todos los datos de contacto de los miembros del GIF (ya les había enviado una versión con fecha 21 de agosto).

Saludos,

Luis


08/25/06 15:23  - sotero

Hola, hay un tema que nos surgió respecto del formato de firma propuesto hasta acá. Tiene que ver con la numeración del COD y el time-stamping. En la operatoria manual, la numeración la hace la EH una vez que está aprobado el COD.
La solicitud que llega a la EH firmada por el Exportador, no está numerada.
De esta manera la EH controla su numeración correlativa y ascendente.
Una propuesta que ya hable con Enrique, sería de extraer el numero del COD del tag <COD> que firma el Exportador, e incluir el número y la fecha-hora antes del tag </CodExportador>.
Esto lo haria la EH antes de firmar el COD, y no tiene efecto sobre el reference URI que firmó el Exportador.
Enrique armó un par de documentos, que reflejan estos cambios. Espero que los envíe a Luis, para que el GIF los considere.
Saludos, Sergio


08/23/06 14:53  - almeida

Sergio:
A mi me interesaria un CERTFICADO x.509 para poder hacer pruebas.


Gracias
Enrique Almeida
Uruguay


08/23/06 14:49  - sotero

Hola, yo nuevamente.
Enrique Almeida me comento que la clase solo generaba una de las firmas. La idea era mostrar un poco el tema del codigo. Para cumplir estrictamente con el formato consensuado, generé una segunda version de la clase EnvelopeSigner que tiene hardcodeada el Id del EH y del Expo. La clase y el XML obtenido se las mande a Luis para que las publique.
Cabe comentar que esta hardcoded el SignerId, y que firma ambas veces con el mismo Certificado. El tema es dar un instrumento para autogenerarse XML firmados con este codigo Java. Puedo proporcionar un Certificado en formato PKCS12 y un COD.XML para aquellos que lo necesiten.
Saludos,
Sergio


08/23/06 14:36  - lcasaco

Los archivos a los que Sergio se refiere están disponibles en http://foros.aladi.org/gtah/XMLsigner.zip
Saludos,
L.


08/23/06 12:31  - picaza


Mercosur Aduana de Chile
General Preferencial
Argentina 12.021 66.268
Uruguay 784 2.538
Paraguay 663 1.046
Brasil 14.541 57.579
TOTAL DI 28.009 127.431



08/23/06 12:02  - sotero

Hola, me confirma Luis que ya estan disponibles los archivos que enviara por email. Consta de un par de clases que firma y chequea el COD.xml segun la version de Enrique.
De todas maneras, Enrique me remarco que falta una de las firmas, y la idea era mostrar el codigo y luego ir depurandolo. Estoy trabajando en una version que contenga el comentario de Enrique. Saludos! Sergio

El email respectivo fue :
Hola, usando el ejemplo propuesto por Enrique, adapte el applet que llevé a Montevideo para que firme enveloped y cumpla con lo consensuado hasta acá.
Supongo que se puede optimizar ya que no es mi fuerte el tema de Java, pero este código puede ayudar.
Basicamente, mando dos clases una EnvelopeSigner que genera el formato que estamos conversando, y la clase que chequea la firma. Envelope Signer, recibe un archivo a firmar y un signer ID (EH o Expo). También recibe un certificado X509 y su clave privada. (No esta usando Assembla)
La clase de chequeo, solo recibe un XML firmado y chequea que este OK la firma.(checkXMLDsig.java)
Adjunto el XML de salida de la clase de firma.(miXMLFirmado.xml)


08/22/06 13:25  - almeida

No recuerdo que se discutiera el tema de las plantillas XSLT.
Para mi va a tener que existir algun conjunto al menos una plantilla basica, que debe ser consensuada:

De cualquier forma, cualquier integrante de la cadena, va a poder utilizar un XSLT diferente, para mostrar la informacion en el formato o para el dispositivo que se desee.

Uno de los pedidos era NO INCLUIR la referencia al XSLT en los items que van a ser firmados (COD o CODExportador), de forma de poder utilizar diferentes nombres para los mismos.

Enrique Almeida
Aduana de Uruguay


08/22/06 13:13  - sotero

Tengo una duda respecto a las plantillas XSL correspondientes a cada ACE. El productor - exportador presentara un COD.XML emitido por una EH. La plantilla correspondiente a ese COD.XML, será provista por la EH? Es parte del producto, o cada receptor contara con planillas XSL que permitan la visualizacion? No recuerdo que es lo acordado sobre este particular. Saludos, Sergio.


08/18/06 13:48  - sotero

Parece que este tema va llevar un tiempo...
Creo que es una cuestion de entorno. Nosotros en la CERA, damos un servicio a nuestros clientes productores-exportadores. No interactuamos a nivel de sistema con la Aduana ni con el importador destino.
Eso hace que nuestra elección no sea un Web Service. Registramos su DDJJ firmada digitalemente, soportamos la solicitud/obtencion de un COD,dandole a la CERA los mecanismos de control adecuados y entregamos un COD.XML adecuado a la norma consensuada. El prod-exp llevara ese COD.XML de alguna manera hasta el importador, que a su vez, lo presentara ante la aduana pertinente.Quizas en otros entornos, que necesiten interactuar a nivel de sistema la opcion de un web service sea lo indicado.


08/18/06 13:37  - picaza

Yo creo que el tema no es irrelevante, ya que cuando tengamos que comunicarnos entre nosotros puede representar un problema, no estoy seguro voy a investigar, pero creo que el punto de union de ambos mundos es el Web Service , deberian leer http://msdn.microsoft.com/webservices/default.aspx?pull=/library/en-us/dnwebsrv/html/wsmsplatform.asp que habla de web serbvices en .Net , no pretendo polemizar pero si no vamos a poder comunicar los COD de nada sirve


08/18/06 13:10  - sotero

Propongo dar por terminado, el tema MS vs. resto del mundo, ya que no aporta nada a la solucion que estamos buscando. Cada cual, en su entorno elige lo que mejor puede o le conviene y listo. Para aquellos que siguen interesados en la alternativa Java, en org.apache.xml.security (http://xml.apache.org/security/dist/java-library/xml-security-bin-1_2_1.zip), hay unos ejemplos que involucran XPath para mostrar tres personas que firman un contrato.El ejemplo se llama ThreeSignerContractSign.java. Claro que usan HMAC y no RSA, pero la idea estaria...


08/18/06 12:13  - picaza

Yo desconosco el Lado Oscuro de La Fuerza, llege con ellos hasta VB 6.0, pero creo que no deberia ser muy diferente el tema, tal como lo dije antes en .Net se pueden hacer Web Services con SOAP y SSL , ya que veo a ustedes haciendo una mescla de .Net con Java que no me parece sana, o al menos complicar algo, yo no mesclaria tecnologias, o lo hago con .Net todo o con Java todo.


08/18/06 10:38  - sotero

En realidad .Net no fue una eleccion para nosotros, es lo que hay... como decimos aca. Otro tema importante para los usuarios de .Net que esten pensando en un ambiente ASP.NET es que la firma de los COD debe hacerse en el cliente (ya que el es el que posee su clave privada) y debe poder visualizar y dar conforme al acto explicito de firmar. La solucion que encontramos a esto fue:
0) ActiveX (ni lo pensamos)
1) Encodear en base64 a la hora de realizar transmisiones, cualquier variable que cotenga tags. (no es relevante si esta firmado o no)
2) Desarrollar la firma como un applet de Java que es invocado desde la pagina posteada por el server.
Este componente tenia un problema adicional, que es acceder al store local (cliente) de certificados. Habia dos caminos : uno via c++/JNI -otro usando Assembla JCE.
Usamos Assembla para acceder localmente al keystore (hay ejemplos en el pdf que esta en su web (https://download.assembla.se/jceprovider/)
Espero esto sea util... Saludos, Sergio


08/18/06 10:28  - almeida

picaza:
Miro el documento que pasate, gracias.
Aun no llegue al analisis de seguridad. Por el momento estoy en la etapa de lograr leerlo sin problemas. De nada me sirve que el mensaje sea seguro, si cuando lo voy a leer, me da un error y no me deja terminar de leerlo.
Si ya hay antecedentes que con .NET tuvieron problemas al leerlo (aun a mi no me paso), este foro es el lugar para plantearlos y encontrarle soluciones.

Enrique Almeida
Concepto (por aduana de uruguay)


08/18/06 10:11  - picaza

Yo no quiero ser peroyativo con el mundo Microsoft, sino agregarle algo de humor al tema, pero como los que están en .Net leen Artículos de Microsoft nosotros leemos la competencia, creo que seria bueno que leyeran este articulo http://www-128.ibm.com/developerworks/library/ws-soapsec/ que es de IBM.


08/18/06 09:00  - almeida

Creo que estos son los problemas que tenemos que empezar a resolver con las pruebas de interoperabilidad.
Nosotros tambien estamos usando .NET ("lado oscuro de la fuerza") y me gusta conocer los problemas que han tenido otros a recibir mensajes en esa plataforma y las formas de resolverlo.
El objetivo de este grupo es diseñar algo que funcione tanto en varias plataformas (al menos en java y .net) y que todos podamos leer en forma segura los mensajes de todos.

El problema de xml injection aun no estoy en condiciones opinar sobre si usar base64 o no pues aun no lo hemos evaluado.

Con respecto al usar 2 firmas, o solo 1. Me inclino por usar 2 firmas y poner un nuevo tag que incluya COD + FIRMA EXPORTADOR.

Otro tema:
Deberiamos definir rapidamente el XML Schema del COD, no?. Hay que incorporarle todos los campos que se discutieron en la reunion, ajustar los tipos de datos y tambien elegir de una vez por todas los tags a utilizar.
Voy a revisar la version Argentina, y le voy a agregar los campos de la planilla excel, que se vio en la reunion prescencial.


08/17/06 19:52  - picaza

sotero, lo que pasa es que ustedes trabajan en el lado oscuro de la fuerza, y es ahi donde se corre peligro de injeccio, en cambio en el lado open utilisando SOAP y SSL se establece un canal privado en que se evita la injeccion.


08/17/06 13:18  - lcasaco

Para conocimiento: Los primeros mails intercambiados fueron incorporados en el documento http://foros.aladi.org/gtah/primeros-mails-GIF.doc


08/17/06 13:00  - lcasaco

Por favor, utilicen el Foro para comunicarse...


08/17/06 12:25  - sotero

En el caso de nuestra aplicacion, y supongo que en general de las camaras, el prod-exp desde su oficina se aplica sobre un formulario web. Cuando esa informacion es enviada al server, viaja en una variable, si esa variable contiene al XML (firmado o no firmado) en texto plano, .Net interpreta un " ...potentially dangerous Request.Form value was detected from the client ..."
Al encodear esa variable en base64, el uso de 2 a la 6 caracteres evita aquellos que el servidor interpreta como intento de ataque. De todas maneras, como habia otras Camaras y quizas se topen con este problema, es que surgio el comentario. Si no te aplica, podes desechar el comentario. Saludos


08/17/06 12:09  - picaza

1.- El codificar en base64 no impide la injeccion
2.- Un documento XML Firmado cualquier injeccion lo invalida


08/17/06 11:50  - sotero

Bien, en http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnpag2/html/WSS_Ch5_MsgVal.asp
hay recomendaciones para prevenir xml injections en web services.
Y en A Guide to Building Secure Web Applications and Web
Services (http://landau.dsic.upv.es/pbs/OWASPGuide2.0.1.pdf)
hay todo un capitulo de injections.
De todas maneras, si no te parece relevante, es solo una recomendacion basada en nuestra experiencia, asi que no la tomes en cuenta y no hay problema....


08/17/06 11:39  - picaza

No es necesario codificar en base64 si no se va a representar un contenido binario.
Nuestros sistemas que corren en una plataforma j2ee utilizan webservices y la comunicación entre Webservices
se basa en protocolo SOAP, que utiliza como transporte HTTP para mandar la data en formato XML sin ser necesario codificar.
Desconozco el caso de .Net, pero en .net también se usan webservices.


08/17/06 11:34  - picaza

Un mensaje XML que es solo TEXTO no puede ser considerado como codigo Malicioso, y que no es posible ejecutar, como si es el caso de un .zip o un .exe etc


08/17/06 11:03  - sotero

Hola, la recomendacion del COD en base 64 responde a un tema de implementacion. En los sistemas que se manejen en .Net y supongo que otras tecnologias basadas en server, el envio de tags en el stream de datos es interpretado como codigo malicioso. Entonces, se utiliza esa codificacion para la transimision. Fue un comentario en particular sobre un problema que nosotros tuvimos a la hora de testear nuestro sistema.


08/17/06 10:48  - picaza



¿Por qué se recomienda usar Base64? , lo que tengo entendido que el COD no tiene elementos Binarios que recomienden usar Base64


08/17/06 10:22  - lcasaco

Estimados:

A solicitud de algunos de los colegas del GIF, y considerando la necesidad de ordenar la participación de todos y el contenido de lo que se vaya creando, abrimos este foro GIF, para tal efecto. Además, es importante que los colegas del GT que no son informáticos, pero que quieren seguir el desarrollo y evolución del trabajo técnico, puedan asomarse a este intercambio de algorítmos y códigos.

Sergio, Enrique y Bernardino, les pregunto: ¿Les parece bien que cuelgue un .doc en la sección documental con estos primeros intercambios (considerando los efectos visuales del color y las "negritas", o Uds. prefieren copy/paste sus mensajes en este foro?. Díganme qué les parece mejor que haga?

Saludos,

Luis


 Ingresar su comentario
Comment Board developed by yMonda Limited.