Bem vindo ao nosso Blog
Dicas e melhores práticas para facilitar a integração com a iVarejo.

Integração do Serviço de Captura Síncrono B2B com PHP

postado em 18 de abr de 2013 14:10 por Usuário desconhecido   [ 23 de jul de 2013 09:48 atualizado‎(s)‎ ]

A iVarejo disponibiliza 2 serviços de captura para integração. Neste post, vamos falar especificamente do serviço de captura Síncrono B2B, integrando-o com a linguagem de programação PHP.

Antes de abordar os quesitos técnicos da integração, é importante acessar a página de integração de Web Services B2B, pois nessa página constam todos os dados necessários para consumo deste serviço.

Em anexo, segue a página com exemplo funcional da integração que pode ser executado em seu ambiente.

Requisitos mínimos para funcionar no PHP

  • PHP 5 com a extensão SoapClient.


Obs: Os atributos das mensagens que não são obrigatórios não devem ser declarados nos parâmetros da chamada do serviço (vide exemplo em anexo).

Em breve novo post para integração B2C via PHP.



Integração Pop-Up com Post/XML‎ (via ASP)

postado em 16 de mai de 2012 07:25 por Usuário desconhecido

por Filipe Abelha

Nos últimos posts (1 e 2) vimos o processo de funcionamento da integração pop-up com Post/XML, utilizando a tecnologia Microsoft ASP .NET. Para simplificar a integração do PDV com a plataforma iVarejo, nós desenvolvemos uma aplicação exemplo em tecnologia ASP, ainda muito utilizada. Ela se encontra na página da integração pop-up com Post/XML (aqui). Então sugiro que você baixe o arquivo "meioPagamentoiVarejo.asp", para conseguir acompanhar melhor o seu funcionamento.

A aplicação exemplo

Esta aplicação foi desenvolvida em ASP (Active Server Pages), portanto não está compilada (o ASP é interpretado). Abrindo o arquivo podemos ver uma série de métodos implementados e no final a página propriamente dita. Agora veremos as particularidades de cada um desses elementos.

O código presente entre as linhas 3 e 11 realiza a execução das procedures principais "EnviaPedido", "RequisitarSegundaViaBoletos" e "ObtemStatusMeioPagamento" de acordo com a ação realizada.


private sub EnviaPedido()

Procedure responsável pelo envio de pedidos para a iVarejo. Esse método executa os seguintes passos:
  • Cria uma conexão com o webservice de entrada de pedido; 
  • Monta e carrega o XML, através dos métodos "MontarXMLEnvioMeioPagamento" e "LoadXML" (do "Microsoft.XMLDOM"), respectivamente;
  • Executa o post para o serviço de entrada de pedido;
  • Carrega o XML de retorno;
  • Trata o retorno do XML, através do método "TrataRetornoEntradaPedido";
  • Caso ocorra algum erro, ele é tratado através da procedure "TrataErro".

private sub ObtemStatusMeioPagamento()

Procedure responsável por requisitar o status do pagamento realizado na iVarejo. Esse método executa os seguintes passos:
  • Cria uma conexão com o webservice de retorno de processamento de pedido;
  • Monta e carrega o XML, através dos métodos "MontarXMLRequisicaoStatusPagamento"  e "LoadXML" (do "Microsoft.XMLDOM"), respectivamente;
  • Executa o post para o serviço de retorno de processamento de pedido;
  • Carrega o XML de retorno;
  • Trata o retorno do XML, através do método "TrataRetornoStatusMeioPagamento";
  • Caso ocorra algum erro, ele é tratado através da procedure "TrataErro".

private sub RequisitarSegundaViaBoletos()

Procedure responsável por requisitar o envio da segunda via dos boletos. Esse método executa os seguintes passos:
  • Cria uma conexão com o webservice de segunda via de boletos;
  • Monta e carrega o XML, através dos métodos "MontarXMLRequisicaoSegundaViaBoletos"  e "LoadXML" (do "Microsoft.XMLDOM"), respectivamente;
  • Executa o post para o serviço de segunda via de boletos;
  • Carrega o XML de retorno;
  • Trata o retorno do XML, através do método "TrataRetornoRequisicaoSegundaViaBoletos";
  • Caso ocorra algum erro, ele é tratado através da procedure "TrataErro".

private sub TrataRetornoEntradaPedido(retorno)

Procedure responsável por tratar o retorno do serviço de entrada de pedido. Esse método cria um javascript para a abertura da pop-up modal e define novamente a url original para a geração de postback, a fim de permitir a obtenção do status do pagamento assim que o fluxo de pagamento for finalizado. Observe que a altura e a largura da pop-up já se encontram no exemplo, de modo que a sua alteração diminuirá a qualidade da experiência dos seus clientes.


private sub TrataRetornoRequisicaoSegundaViaBoletos(retorno)

Procedure responsável por tratar o retorno do serviço de segunda via dos boletos. Caso o código retornado seja 
"IVJ.ECOMMERCE.RET.100", os boletos foram gerados com sucesso.


private sub TrataRetornoStatusMeioPagamento(retorno)

Procedure responsável por tratar o retorno do serviço de retorno do processamento do pedido. Cada código retornado possui um significado diferente, seguem os significados a seguir:
  • "IVJ.ECOMMERCE.RET.002": pagamento finalizado com sucesso;
  • "IVJ.ECOMMERCE.RET.003": pagamento cancelado pelo cliente em algum momento do fluxo;
  • "IVJ.ECOMMERCE.RET.004": utilização da iVarejo não aprovada como meio de pagamento para aquele pedido;
  • "IVJ.ECOMMERCE.FPI.000": fluxo interrompido pelo cliente pelo cancelamento do passo "análise de risco";
  • "IVJ.ECOMMERCE.FPI.001" fluxo interrompido pelo cliente pelo cancelamento do passo "dados da compra";
  • "IVJ.ECOMMERCE.FPI.002"fluxo interrompido pelo cliente pelo cancelamento do passo "dados do consumidor";
  • "IVJ.ECOMMERCE.FPI.003": fluxo interrompido pelo cliente pelo cancelamento do passo "plano de pagamento";

private function MontarXMLEnvioMeioPagamento()

Função responsável pela geração do XML de envio para o meio de pagamento.


private function MontarXMLRequisicaoStatusPagamento(idTransacao)

Função responsável pela geração do XML de requisição do status do pagamento.


private function MontarXMLRequisicaoSegundaViaBoletos()

Função responsável pela geração do XML de requisição da segunda via de boletos.


private sub TrataErro(retorno)

Procedure responsável pelo tratamento de erros. Cada código retornado possui um significado diferente, seguem os significados a seguir:
  • "IVJ.ECOMMERCE.ERR.FP1": erro no passo "dados da compra";
  • "IVJ.ECOMMERCE.ERR.FP2": erro no passo "dados do consumidor";
  • "IVJ.ECOMMERCE.ERR.FP3": erro no passo "plano de pagamento";
  • "IVJ.ECOMMERCE.ERR.FP4": erro no passo "finalização de pagamento";
  • "IVJ.ECOMMERCE.ERR.FP7": erro na impressão de boletos;
  • "IVJ.ECOMMERCE.WSVCCONTENTFAULT": erro no formato do XML;
  • "IVJ.ECOMMERCE.INTERNALFAULT": erro interno.

private function CapturaErro(message)

Função de suporte para identificação de retorno de erro pela iVarejo.



No próximo post trataremos da integração sem pop-up, utilizando POST/FORM. Até lá!



tags: #integracao, #xml, #asp, #aspclassico

Fontes:

---

Integração Pop-Up com Post/XML‎ (via ASP .NET) - Conector iVarejo

postado em 12 de fev de 2012 17:02 por Usuário desconhecido

por Filipe Abelha

Como prometido no post anterior, hoje analisaremos o funcionamento interno do conector iVarejo. Recapitulando, esse conector é fornecido através do assembly "iVarejo.Ecommerce.EAI.Conector.dll" e nele encapsulamos boa parte da lógica de integração, implementando os métodos e objetos que são utilizados. Nele são implementados os seguintes métodos:

public void IniciarPagamentoPedido(DadosPagamento dadosPagamento, Page page);

Envia as informações do pedido para a iVarejo.

public RetornoPagamentoPedido ObterRetornoMeioPagamento();

Recebe as informações de retorno do pagamento, conforme visto no último post.

public bool RequisitarSegundaViaBoletos(DadosRequisicaoSegundaViaBoletos dadosRequisicaoSegundaVia);

Solicita a segunda via dos boletos referentes à um determinado pedido.


Vamos analisar como funciona cada um desses métodos, para facilitar a compreensão serão definidos os principais passos de execução (como se estivéssemos "debugando" o código):


IniciarPagamentoPedido

1 - Instanciação de um objeto do tipo HttpWebRequest com a URL definida na diretiva "IVJ_URL_ENVIO_DADOS_PEDIDO" cadastrada no web.config. Este objeto tem um conteúdo do tipo "text/xml", com método do tipo "POST" e com um CokieContainer instanciado.

2 - Instanciação de um objeto do tipo StreamWriter com o stream do objeto criado no passo 1.

3 - Transforma o objeto do tipo DadosPagamento informado na chamada em um tipo interno e este é convertido para um XML e o escreve no objeto criado no passo 1.

4 - Instanciação de um objeto do tipo HttpWebResponse com o response do objeto criado no passo 1.

5 - Instanciação de um objeto do tipo StreamReader com o stream do objeto criado no passo 4.

6 - Obtenção do XML de retorno contido no objeto criado no passo 5.

7 - Conversão do XML obtido no passo 6.

8 - Criação de um string contendo o javascript a ser utilizado para a abertura do pop-up do meio de pagamento da iVarejo, de acordo com o browser utilizado pelo usuário.

9 - Execução do script e abertura do pop-up do meio de pagamento da iVarejo.


ObterRetornoMeioPagamento

1 - Instanciação de um objeto do tipo HttpWebRequest com a URL definida na diretiva "IVJ_URL_RETORNO_STATUS_MEIO_PAGAMENTO" cadastrada no web.config. Este objeto tem um conteúdo do tipo "text/xml", com método do tipo "POST" e com um CokieContainer instanciado.

2 - Instanciação de um objeto do tipo StreamWriter com o stream do objeto criado no passo 1.

3 - Obtenção do IdTransação da QueryString.

4 - Converte um objeto interno com o IdTransacao para um XML e o escreve no objeto criado no passo 1.

5 - Instanciação de um objeto do tipo HttpWebResponse com o response do objeto criado no passo 1.

6 - Instanciação de um objeto do tipo StreamReader com o stream do objeto criado no passo 4.

7 - Obtenção do XML de retorno contido no objeto criado no passo 5.

8 - Conversão do XML obtido no passo 7 em um objeto do tipo RetornoPagamentoPedido.

9 - Retorno do objeto criado no passo 8.



RequisitarSegundaViaBoletos

1 - Instanciação de um objeto do tipo HttpWebRequest com a URL definida na diretiva "IVJ_URL_REQUISICAO_SEGUNDA_VIA_BOLETOS" cadastrada no web.config. Este objeto tem um conteúdo do tipo "text/xml", com método do tipo "POST" e com um CokieContainer instanciado.

2 - Instanciação de um objeto do tipo StreamWriter com o stream do objeto criado no passo 1.

3 - Transforma o objeto do tipo DadosRequisicaoSegundaViaBoletos informado na chamada em um tipo interno e este é convertido para um XML e o escreve no objeto criado no passo 1.

4 - Instanciação de um objeto do tipo HttpWebResponse com o response do objeto criado no passo 1.

5 - Instanciação de um objeto do tipo StreamReader com o stream do objeto criado no passo 4.

6 - Obtenção do XML de retorno contido no objeto criado no passo 5.

7 - Conversão do XML obtido no passo 6.

8 - Caso o retorno tenha sinalizado um correto envio da segunda via, retorna true. Caso contrário, false.



Este post não tinha como objetivo ensinar os conceitos tecnológicos envolvidos na integração, mas sim informar quais passos cada método executava. Caso exista alguma dúvida no conteúdo abordado, sugiro uma pesquisa rápida na MSDN Library.


tags: #integracao, #xml

Fontes:

---

Integração Pop-Up com Post/XML‎ (via ASP .NET)

postado em 19 de dez de 2011 03:37 por Usuário desconhecido

por Filipe Abelha

No último post vimos o processo de funcionamento da integração pop-up com Post/XML. Como prometido, hoje começaremos a ver como essa integração funciona na prática, iniciando com a tecnologia Microsoft ASP .NET.

Nós criamos uma aplicação exemplo utilizando essa tecnologia, ela se encontra na página da integração pop-up com Post/XML (neste link). Então eu sugiro que você baixe os arquivos "ExemplosIntegracaoEcommerceiVarejo.zip" (aplicação exemplo) e "iVarejo.Ecommerce.EAI.Conector.dll" (conector) para conseguir acompanhar melhor o seu funcionamento.


A aplicação exemplo

Esta solução está compilada na versão 3.5 do Microsoft .NET Framework, mas a sua atualização para a versão 4.0 acontece de forma automática pelo Visual Studio 2010 (caso seja necessário).

Abrindo a aplicação é possível ver o conector na pasta "External References" e um projeto web chamado "ExemploPopup", que contém 2 páginas "default.aspx" e "retornomeiopagamento.aspx", uma classe "util.cs" e o "web.config". Agora vamos ver as particularidades de cada um desses elementos.


iVarejo.Ecommerce.EAI.Conector.dll

Nós desenvolvemos esse conector para facilitar a vida do programador. Nele é encapsulada boa parte da lógica de integração: os métodos e objetos que são utilizados. Por hora é importante saber que esse conector provê acesso aos métodos e classes:

public void IniciarPagamentoPedido(DadosPagamento dadosPagamento, Page page);

Envia as informações do pedido para a iVarejo.

public RetornoPagamentoPedido ObterRetornoMeioPagamento();

Recebe as informações de retorno do pagamento, conforme visto no último post.

public bool RequisitarSegundaViaBoletos(DadosRequisicaoSegundaViaBoletos dadosRequisicaoSegundaVia);

Solicita a segunda via dos boletos referentes à um determinado pedido.


default.aspx

Essa página trata do envio das informações do pedido para a iVarejo. Para tal, devemos preencher uma instância da classe "DadosPagamento" com todas as informações do pedido, de forma semelhante ao que é visto no método "protected void btnPagar_Click(object sender, EventArgs e)".

Em seguida, chamamos o método "IniciarPagamentoPedido
"
do conector, que iniciará o processo de pagamento.


retornomeiopagamento.aspx

No final do processo de pagamento, ou por conta de um erro, ou mesmo pelo cancelamento do consumidor, a iVarejo realiza um comando POST chamando a página de retorno do ecommerce. É quando o método "ObterRetornoMeioPagamento" é chamado e devemos tratar as informações que recebemos através de um objeto do tipo "RetornoPagamentoPedido", de forma semelhante ao que é visto no método "protected void Page_Load(object sender, EventArgs e)".


util.cs

Essa classe é utilizada apenas para gerar o número do pedido para esse exemplo. Não recomendamos a sua utilização no ecommerce.


web.config

Este arquivo é padrão para qualquer aplicação ASP .NET. Entretanto para a utilização do conector é necessário incluir as seguintes informações dentro da área <configuration> -> <appSettings>:

<add key="IVJ_URL_ENVIO_DADOS_PEDIDO" value="http://srvdes01/ecommerce.servicos/AppLevel/entradapedido.wsvc"/>

URL que forneceremos para o envio das informações do pedido.


<
add key="IVJ_URL_RETORNO_STATUS_MEIO_PAGAMENTO" value="http://srvdes01/ecommerce.servicos/AppLevel/retornoprocessamentopedido.wsvc"/>

URL que forneceremos para a requisição do retorno das informações do pagamento.


<
add key="IVJ_URL_REQUISICAO_SEGUNDA_VIA_BOLETOS" value="http://srvdes01/ecommerce.servicos/AppLevel/segundaviaboletos.wsvc"/>

URL que forneceremos para a requisição da segunda via dos boletos de um determinado pedido.


<
add key="IVJ_URL_PAGINA_RETORNO_ECOMMERCE" value="http://localhost/ExemploPopup/retornomeiopagamento.aspx"/>

URL da página de retorno do ecommerce.


Viu como é fácil? Utilize o conector e boa parte dos seus problemas estarão solucionados!  =)




No próximo post falaremos sobre o funcionamento interno do conector.



tags: #integracao, #xml

Fontes:

---

‎Integração Pop-Up com Post/XML‎ (parte I)

postado em 21 de nov de 2011 05:32 por Usuário desconhecido   [ 30 de abr de 2012 08:28 atualizado‎(s)‎ ]

por Filipe Abelha

Nos últimos posts falamos sobre as características e a estrutura de documentos XML. Da mesma forma que já abordamos a integração pop-up com POST/FORM (aqui, aqui e aqui), vamos aproveitar que já possuímos embasamento para falar de mais uma forma de integração entre os ecommerces e o meio de pagamento disponibilizado pela iVarejo: o pop-up com POST/XML.

O controle do processo de pagamento acontece no domínio da iVarejo, retirando grande parte da complexidade de implementação necessária dos outros modelos (de forma análoga ao pop-up com POST/FORM). As lojas virtuais, hotsites e ecommerces que adotarem este padrão encapsularão os dados de seus formulários em um documento XML antes do envio para a iVarejo.


Fluxo de execução

O fluxo de sequência de troca de mensagens acontece na seguinte ordem:




A estrutura das mensagens trocadas entre o ecommerce e a iVarejo já estão bem detalhadas na documentação (aqui), então vamos focar em definir o conteúdo de cada uma delas e a motivação para a existência de cada método.

1 - Serviço "entradapedido.wsvc":
     - recebe a mensagem "EnvioMeioPagamento" que possui as informações referentes ao pedido, assim como os dados do consumidor que o está realizando.
     - retorna a mensagem "RetornoMeioPagamento" que possui informações referentes à autorização do meio de pagamento.

2 - Se o retorno for de pagamento autorizado, o ecommerce chama a página Pagamento.aspx, onde o consumidor confirma os seus dados, escolhe o plano de pagamento e efetiva a compra. Após a ação do consumidor, o ambiente da iVarejo retorna a navegação para o ecommerce.

3 - Serviço "retornoprocessamentopedido.wsvc":
     - recebe a mensagem "RequisicaoStatusPagamento" com o id da transação realizada.
     - retorna a mensagem "RetornoMeioPagamento", que agora possui status de concluído (caso o consumidor tenha finalizado o processo com sucesso) ou de cancelado (caso o consumidor tenha cancelado o processo em qualquer etapa).


O ecommerce deverá tratar os retornos de acordo com os seus status:

- IVJ.ECOMMERCE.RET.001: meio de pagamento autorizado. O processo deve ter prosseguimento.
- IVJ.ECOMMERCE.RET.002: processo de compra concluído.
- IVJ.ECOMMERCE.RET.003: processo de compra cancelado.
- IVJ.ECOMMERCE.RET.004: meio de pagamento não autorizado.
- IVJ.ECOMMERCE.RET.100: envio de segunda via realizado com sucesso.



Para os casos em que o consumidor solicite uma segunda via de seus boletos, o ecommerce deve implementar uma funcionalidade que acessa o serviço "segundaviaboletos.wsvc":
     - recebe a mensagem "DadosSegundaViaBoletos" que possui a identificação do ecommerce e do pedido.
     - retorna a mensagem "RetornoMeioPagamento" com o código de retorno correspondente.



Nos próximos posts forneceremos exemplos de integração em ASP .NET e ASP.




tags: #integracao, #xml

Fontes:

---

XML - DTD

postado em 7 de nov de 2011 04:10 por Usuário desconhecido

por Filipe Abelha

No último post introduzimos a linguagem de marcação XML: sua definição e estrutura. Agora vamos abordar uma das ferramentas de validação de estrutura de um documento XML, o Document Type Definition (DTD).

A W3C define o DTD como uma ferramenta de validação da construção dos blocos de um documento XML, através de uma lista de elementos e atributos que são esperados ou obrigatórios. O DTD pode ser declarado tanto no mesmo arquivo do XML, quanto em um arquivo separado.

Estrutura do DTD

Para melhor exemplificar a estrutura do DTD, vamos inserí-lo no arquivo XML do nosso exemplo de uma receita de pão simples do último post:

01 <?xml version="1.0" encoding="UTF-8"?>
02
03 <!DOCTYPE receita [ 04 <!ELEMENT receita (titulo,ingredientes,instrucoes)> 05 <!ELEMENT titulo (#PCDATA)> 06 <!ELEMENT ingredientes (ingrediente+)>
07 <!ELEMENT ingrediente (#PCDATA)>
08 <!ELEMENT instrucoes (passo+)>
09 <!ELEMENT passo (#PCDATA)>
10
11 <!ATTLIST receita nome CDATA #REQUIRED>
12 <!ATTLIST receita tempo_de_preparo CDATA #REQUIRED>
13 <!ATTLIST receita tempo_de_cozimento CDATA #REQUIRED>
14 <!ATTLIST ingrediente quantidade CDATA #REQUIRED>
15 <!ATTLIST ingrediente unidade CDATA #REQUIRED>
16 <!ATTLIST ingrediente estado CDATA #IMPLIED>
17 ]>
18
19 <receita nome="pão" tempo_de_preparo="5 minutos" tempo_de_cozimento="1 hora"> 20 <titulo>Pão simples</titulo> 21 <ingredientes> 22 <ingrediente quantidade="3" unidade="xícaras">Farinha</ingrediente> 23 <ingrediente quantidade="7" unidade="gramas">Fermento</ingrediente> 24 <ingrediente quantidade="1.5" unidade="xícaras" estado="morna">Água</ingrediente> 25 <ingrediente quantidade="1" unidade="colheres de chá">Sal</ingrediente> 26 </ingredientes> 27 <instrucoes> 28 <passo>Misture todos os ingredientes, e dissolva bem.</passo> 29 <passo>Cubra com um pano e deixe por uma hora em um local morno.</passo> 30 <passo>Misture novamente, coloque numa bandeja e asse num forno.</passo> 31 </instrucoes> 32 </receita>

O DTD está inserido entre as linhas 3 e 17, onde:

- todo DTD começa com a tag DOCTYPE e com o nome da estrutura que existe no arquivo XML (receita no nosso exemplo).
- todo elemento do documento XML é declarada através das estruturas <!ELEMENT nome-do-elemento categoria> (quando não possui sub-elementos) e <!ELEMENT nome-do-elemento (elementos filhos)> (quando possuem sub-elementos); como exemplos, temos as linhas 5 e 4, respectivamente.
- #PCDATA significa que os dados serão interpretados pelos sistemas, por exemplo: o 0 (zero) apesar de estar representado pelo caracter '0', deverá ser interpretado como um número.
-
o sinal "+" nos sub-elementos das linhas 6 e 8 indicam que deve existir ao menos uma ocorrência daquele sub-elemento.
- todo atributo de elemento do documento XML é declarado através da estrutura <!ATTLIST nome-do-elemento nome-do-atributo tipo-do-atributo necessidade-de-ocorrencia>.
- #REQUIRED e #IMPLIED são utilizados quando o atributo é obrigatório ou não obrigatório, respectivamente, em cada ocorrência do elemento.

Para maiores detalhes sobre as regras e o funcionamento do DTD, sugiro o acesso aos links de referência ao final do post.


No próximo post colocaremos os assuntos que vimos nas últimas semanas em prática, pois abordaremos a Integração via Pop-up com Http Post/XML (mais uma forma de integração com a iVarejo)
.




tags: #xml, #dtd, #w3c

Fontes:

http://www.w3schools.com/dtd/default.asp
http://www.w3.org/XML/

XML

postado em 14 de out de 2011 13:02 por Usuário desconhecido

Por Filipe Abelha

Segundo a
W3C, o XML (Extensible Markup Language):
Para melhor entendimento, saiba que a informação estruturada contêm tanto o conteúdo (a informação em si) quanto alguma indicação de como interpretar a informação e a linguagem de marcação é o mecanisco de identificação de estruturas em um documento. A especificação XML define um mecanismo padrão de adicionar marcação em documentos.

Atualmente existem várias implementações baseadas em XML entre elas: RSS, Atom, SOAP, XHTML, Office Open XML, OpenDocument, entre outras; e também implementações de banco de dados com persistência em XML (BaseX, eXist, etc.).

Caso possua interesse em se aprofundar na especificação, sugiro a leitura das referências do texto. Pois agora que já tivemos uma visão geral do XML, vamos vê-lo na prática!


Estrutura do documento XML


Segue um exemplo de documento XML devidamente copiando do seu respectivo verbete na Wikipedia:

01 <?xml version="1.0" encoding="UTF-8"?>
02 <receita nome="pão" tempo_de_preparo="5 minutos" tempo_de_cozimento="1 hora">
03   <titulo>Pão simples</titulo>
04   <ingredientes>
05     <ingrediente quantidade="3" unidade="xícaras">Farinha</ingrediente>
06     <ingrediente quantidade="7" unidade="gramas">Fermento</ingrediente>
07     <ingrediente quantidade="1.5" unidade="xícaras" estado="morna">Água</ingrediente>
08     <ingrediente quantidade="1" unidade="colheres de chá">Sal</ingrediente>
09   </ingredientes>
10   <instrucoes>
11     <passo>Misture todos os ingredientes, e dissolva bem.</passo>
12     <passo>Cubra com um pano e deixe por uma hora em um local morno.</passo>
13     <passo>Misture novamente, coloque numa bandeja e asse num forno.</passo>
14   </instrucoes>
15 </receita>

Onde:
  • As palavras na cor azul são as tags (marcação) e sempre estão delimitadas pelos caracteres "<" e ">"; podem ser tags de início (<tag>), de fim (</tag>) ou sem elementos(<tag />);
  • As palavras na cor vermelha são os atributos (marcação/informação) e consistem sempre em um par nome="valor" inserido em uma tag de início ou em uma sem elementos;
  • As palavras na cor preta são os elementos das tags (informação) e estão sempre inseridos entre um par de tags de início e fim;
  • A primeira linha representa o cabeçalho do documento XML. Apesar de não ser estritamente necessário explicita o tipo de documento (XML) e o padrão de codificação de seu conteúdo.

Esse exemplo de documento XML contém
apenas uma tag/objeto (receita) que possui 3 atributos (nome, tempo_de_preparo, tempo_de_cozimento) com seus respectivos valores e 3 sub-tags/objetos (titulo, ingredientes, instrucoes) e assim sucessivamente.

É importante deixar claro que a escolha entre deixar um valor como atributo de uma tag ou como uma sub-tag vai de acordo com o gosto do freguês. Poderíamos colocar a tag <titulo>Pão simples</titulo> como um atributo da tag <receita>, ficando na estrutura titulo="Pão simples". O XML permite que sejam criadas estruturas de informação de inúmeras maneiras diferentes, com a vantagem de ser inteligível tanto para um sistema, quanto para uma pessoa. Se eu tivesse uma máquina de fazer pão que "entendesse" a estrutura desse XML, ela certamente faria o "Pão simples" perfeitamente.


Nos próximos posts abordaremos um pouco mais sobre as funcionalidades e maneiras de manipulação de documentos XML.



tags: #xml, #segurança, #tsl, #ssl, #w3c

Fontes:

http://www.w3.org/TR/REC-xml/
http://www.w3.org/XML/
http://www.xml.com/
http://pt.wikipedia.org/wiki/XML
http://en.wikipedia.org/wiki/XML
http://www.w3schools.com/xml/
http://en.wikipedia.org/wiki/SGML

TLS / SSL (final)

postado em 22 de ago de 2011 05:34 por Usuário desconhecido

por Rodrigo Rocha

No último post abordamos a origem, definição e estrutura do protocolo de segurança TLS. Hoje serão mostrados os seus subprotocolos e os seus métodos criptográficos.


Subprotocolos

- O protocolo de Registro (Record Protocol)

Este protocolo fragmenta as mensagens em blocos, podendo então comprimí-los, e adiciona a eles um código MAC (Message Authentication Code), encripta e transmite o resultado. Ele também é organizado em camadas. Em cada uma delas, as mensagens podem incluir campos com o tamanho da mensagem, a descrição e o conteúdo.

Os protocolos de Handshaking usam o protocolo de Registro e serão descritos abaixo, eles permitem que ambos os lados da conexão concordem quanto a parâmetros de segurança, métodos criptográficos, autenticação das partes e identificação de erros.


- O protocolo Handshake

É o responsável pela negociação de uma sessão, que é composta do seu identificador, dos certificados padrão X.509 de ambas as partes (ou de apenas um lado), do método de compressão a ser utilizado, das especificações criptográficas (algoritmos de encriptação e autenticação), entre outros.

Os dados contidos neste protocolo servirão de parâmetros para o protocolo de Registro, quando este estiver cuidando da segurança do protocolo de Aplicação. Uma sessão já iniciada pelo protocolo Handshake pode ser retomada, pois este é um recurso do subprotocolo.

Quando cliente e servidor iniciam uma conexão, eles concordam quanto à versão do protocolo que está sendo utilizada, quanto aos algoritmos criptográficos, e fazem a autenticação um do outro. O protocolo implementa isso através da troca de mensagens de “Hello”, da troca de parâmetros de criptografia e da troca de certificados visando a autenticação dos pares.

Funciona como no quadro acima: o cliente primeiro envia um “ClientHello
, ao que o servidor deve responder com um “ServerHello”, definindo então a versão do protocolo, o identificador da sessão, o conjunto de códigos para encriptação, e o método de compressão. Além disso, dois valores aleatórios também são gerados e trocados, para que após seja computado um “segredo” ou código ou chave, que será usado para autenticar ambos os lados junto com os certificados, nas próximas mensagens “Certificate” e “ServerKeyExchange”, terminando com o “ServerHelloDone” que indica o fim da fase “Hello” de handshake.

Em seguida, se o servidor exigir, o cliente também deve apresentar seu certificado, então enviar o “ClientKeyExchange”, cujo conteúdo vai depender dos códigos acordados entre as partes no início da negociação, e pode verificar a autenticidade do certificado do servidor. Após isso, os dois lados trocam “ChangeCipherSpec” e terminam o handshake, podendo então transferir os dados do protocolo de aplicação.


- O Protocolo ChangeCipherSpec

Sua função é marcar as mudanças nos critérios de criptografia. Ele consiste numa única mensagem, que é encriptada e comprimida. Este tipo de mensagem é enviado por ambos os lados da conexão, com o intuito de notificar o outro lado de que as próximas mensagens serão protegidas pelos novos métodos especificados.

O lado que enviar primeiro a mensagem de ChangeCipherSpec não tem conhecimento sobre se o outro lado está pronto para recebê-la e começar a utilizar a nova especificação de encriptamento. Caso a operação que o outro lado esteja executanto seja mais custosa computacionalmente, durante um certo tempo esse lado deverá armazenar as mensagens num buffer, afim de que quando terminar, poder trabalhar segundo as novas especificações.


- O Protocolo de Alerta (Alert Protocol)

O conteúdo de alerta, provido pelo subprotocolo de alerta, também é suportado pelo protocolo de registro. Essas mensagens se distinguem entre avisos e erros fatais e são compostas pelas suas devidas descrições. Alertas fatais resultam em fechamento imediato da conexão, tornando o identificador da sessão inválido, evitando então que esta sessão seja utilizada em novas conexões. Como qualquer outra mensagem, esses alertas também são comprimidos e encriptados para serem então transmitidos.

Aqui é importante dizer que quando há alertas de fechamento, ambos os lados da conexão devem estar cientes que há intenção de fechar a conexão. Dessa forma evita-se alguns tipos de ataques. Qualquer lado pode enviar um alerta de fechamento, indicando que quaisquer dados que sejam enviados após isso devem ser ignorados.


Métodos Criptográficos

- Algoritmo RSA

Este algoritmo é largamente utilizado para criptografar mensagens e é famoso pela grande dificuldade em ser quebrado, sendo então uma ótima opção para encriptar as mensagens transmitidas com o TLS. Ele é composto por um par de chaves, pública e privada. A primeira é de conhecimento de todos os envolvidos e a segunda fica em segredo. As mensagens cifradas com uma chave pública só poderão ser decifradas utilizando uma chave privada que forma o respectivo par de chaves.

São gerados dois pares de números, cada chave é composta de um par, sendo que uma mensagem encriptada com um par só possa ser decriptada com o outro par. Então, o par que representa a chave pública é divulgado, para que o outro lado da conexão encripte a mensagem com esse par. Isso funciona pois apenas o lado que enviou a chave pública poderá decriptar a mensagem, pois ele é o único que possui a chave privada.


- HTTP over TLS

É realmente simples utilizar o HTTP com o TLS, formando o famoso HTTPS, presente na forma de “cadeado” e inicializando as URLs de sites de banco, programas de email, formulários online, etc. A utilização se dá da mesma forma que o HTTP sobre o TCP puro.

Basta que inicie-se a conexão na porta correta (443) com o “ClientHello” do TLS, inicializando então o processo de handshake. Ao final deste processo, o conteúdo HTTP deve ser passado na forma do protocolo de Aplicação do TLS. Nada é alterado dentro do HTTP.


Por que utilizar o TLS /SSL

É possível observar que o protocolo TLS se mostra como uma boa opção para prover segurança às conexões em redes e na Internet. Escolhendo o método de criptografia adequado e dispondo de certificados para realizar a autenticação, é possível realizar transferências seguras e livres de uma grande variedade de ataques.

Quanto à sua aplicabilidade, o TLS é vastamente empregado em diversos tipos de aplicações, podendo ser utilizado com outros protocolos e lhes conferindo segurança necessária na transmissão dos dados. Ainda em relação a um mesmo protocolo, o TLS pode ser aplicado de mais de uma maneira, diversificando o seu raio de atuação.

Por meio da encriptação das mensagens de autenticação dos usuários, este protocolo cumpre os seus objetivos, no tocante a conferir as condições necessárias para que as informações trafeguem com o mínimo de interferência de agentes externos ou atacantes. Permite então a confidencialidade e a eficiência na transmissão dos dados do emissor ao receptor.




Para maiores informações sobre TLS/SSL consulte as referências utilizadas como fontes para este post.




tags: #protocolo, #segurança, #tsl, #ssl

Fontes:

http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2010_2/bernardo/index.html
Dierks, T. and Rescorla, E. "The Transport Layer Security (TLS) Protocol Version 1.2" RFC 5246, IETF 2008.
Rescorla, E. "HTTP over TLS" RFC 2818, IETF 2000.
Ford-Hutchinson, P. "Securing FTP with TLS" RFC 4217, IETF 2005.
http://en.wikipedia.org/wiki/Transport_Layer_Security (acessado em 29/09/2010)

TLS / SSL (parte I)

postado em 10 de ago de 2011 11:35 por Usuário desconhecido   [ 22 de ago de 2011 05:35 atualizado‎(s)‎ ]

Por Rodrigo Rocha

Quando tratamos de aplicações acessadas ou integradas via rede devemos levar em consideração uma série de variáveis: integridade, acessibilidade, segurança... Dentre elas a segurança sempre será uma das nossas principais preocupações. Dentre todas as medidas preventivas que podem ser adotadas, vamos tratar hoje do protocolo de segurança TLS.

A Origem

O protocolo TLS (Transport Layer Security) é o sucessor do antigo SSL (Secure Sockets Layer). O SSL foi desenvolvido pela Netscape, sua versão mais utilizada foi a SSL 3.0, que foi liberada em meados de 1996, já que as anteriores ou não foram liberadas ao público, ou apresentaram inúmeras falhas,.

Em 1999, o IETF (Internet Engineering Task Force) liberou a especificação do TLS 1.0, que não tinha tantas diferenças para o SSL 3.0. Ao longo dos anos, melhorias foram sendo sugeridas e aos poucos implementadas, sendo que em 2006 foi lançada a versão TLS 1.1 e em 2008 foi lançada a última versão, o TLS 1.2.

Conforme o protocolo foi sendo utilizado, surgiram diversas extensões, devidamente aprovadas e definidas pelo IETF, que vão desde a utilização junto com os protocolos HTTP e FTP, que serão abordados neste trabalho, como também o SMTP, IMAP, POP3, e os conjuntos de cifras, fornecendo maior variedade de opções aos usuários.


O Protocolo TLS

Os objetivos deste protocolo são a segurança (por meio de criptografia), a interoperabilidade, a extensabilidade e a eficiência.

Isso quer dizer que este protocolo é capaz de estabelecer uma conexão segura entre duas entidades e de garantir que dois aplicativos consigam se comunicar ou trocar parâmetros independentemente da forma como foram construídos. É também capaz de abarcar futuras extensões, diminuindo a necessidade de se criar um novo protocolo e impedindo a criação de uma nova biblioteca de segurança. Esses dois últimos pontos são muito importantes, já que a criação de um protocolo ou de métodos de segurança podem trazer novos pontos falhos. A eficiência do protocolo vem do número reduzido de conexões necessárias, uma vez que é utilizado cache para guardar certas informações, poupando também tempo de processamento.

Em muitas aplicações, o TLS é apenas unilateral (situação típica da navegação web), ou seja, apenas um dos lados (o servidor) é autenticado, permanecendo o cliente anônimo ou não-autenticado. Apesar disso é plenamente possível que a autenticação seja bilateral, tendo o cliente, portanto, que possuir também um certificado de autenticidade.

Ao estabelecer uma conexão TLS, cliente e servidor negociam um conjunto de códigos, chamado em inglês de CipherSuite, por meio das primeiras mensagens da comunicação. Dessa forma, ambos os lados sabem que algoritmos criptográficos deverão utilizar para encriptar ou decriptar as mensagens. Pode ser usado chave simétrica ou chave assimétrica no processo de autenticação dos participantes.


Estrutura

O Protocolo TLS se situa entre as camadas de Aplicação e Transporte. Ele encapsula os protocolos de aplicação como o HTTP (Hypertext Transfer Protocol) e o FTP (File Transfer Protocol) e trabalha em cima de um protocolo de transporte como o TCP (Transmission Control Protocol) e o UDP (User Datagram Protocol). Para que a transmissão seja confiável, deve ser utilizado o protocolo TCP, uma vez que o UDP está mais sujeito à perdas de informação, já que é datagrama.

Na figura abaixo, é possível enxergar melhor o posicionamento do TLS, em meio às demais camadas:



O Protocolo TLS é composto também de duas camadas, formadas por 2 tipos de protocolos: os protocolos de Handshaking e o Protocolo de Registro. Essa estrutura pode ser melhor observada na figura abaixo:



Os protocolos de Handshaking são utilizados para autenticar cliente e servidor e para negociar algoritmos de criptografia e chaves criptográficas, antes que o protocolo de aplicação seja de fato transmitido. Uma vez que ambos os lados concordem quanto à autenticidade um do outro e também quanto aos parâmetros de segurança, a transmissão segura pode então começar. Esses protocolos de negociação são encapsulados pelo Protocolo de Registro, e então são enviados.


No próximo post serão mostrados os subprotocolos do TLS e os seus métodos criptográficos.



tags: #protocolo, #segurança, #tsl, #ssl

Fontes:

http://www.gta.ufrj.br/ensino/eel879/trabalhos_vf_2010_2/bernardo/index.html
Dierks, T. and Rescorla, E. "The Transport Layer Security (TLS) Protocol Version 1.2" RFC 5246, IETF 2008.
Rescorla, E. "HTTP over TLS" RFC 2818, IETF 2000.
Ford-Hutchinson, P. "Securing FTP with TLS" RFC 4217, IETF 2005.
http://en.wikipedia.org/wiki/Transport_Layer_Security (acessado em 29/09/2010)

Integração via Pop-up com Http Post/FORM (final)

postado em 29 de jun de 2011 07:59 por Usuário desconhecido

por Filipe Abelha

No post anterior, falamos um pouco mais sobre o método POST (das mensagens de request) e sobre a tag html FORM. Agora falaremos sobre a montagem do FORM e como fazemos para integrar com a iVarejo utilizando o Pop-Up com Post/FORM.


Montagem do Form

Como já definimos o html FORM, vamos partir logo para um exemplo com a sua respectiva explicação:

01 <form action="http://sitecadastro.com.br/programa/cadastropessoa" method="post">
02    <p>
03        <label>
04            Nome:
05        </label> 06     <input type="text" id="nome">
07        <br> 08     <label>
09            Sobrenome:
10        </label> 11     <input type="text" id="sobrenome">
12        <br> 13     <label>
14            Email:
15        </label> 16     <input type="text" id="email">
17        <br> 18     <input type="radio" name="sexo" value="Masculino">Masculino
19        <br> 20     <input type="radio" name="sexo" value="Feminino">Feminino
21        <br> 22     <input type="submit" value="Enviar">
23        <input type="reset"> 24 </p> 25 </form>

Linhas 01 e 25 - tag html FORM, com os atributos action (que especifica o endereço para o qual vai a informação do formulário) e method (o método do request (neste caso o post)).

Linhas 02 e 24 - formatação de parágrafo; não influencia o POST, apenas formata a informação do FORM.

Linhas 03 a 05, 08 a 10 e 13 a 15 - textos que nomearão os campos do formulário; não influencia o POST.

Linhas 06, 11 e 16  - tag html que representa uma caixa de texto (representado pelo atributo type="text") e que possibilita a inserção de dados pelo usuário; participam do POST. O acesso a informação correta de cada campo acontece pelo valor do atributo id de cada campo.

Linhas 07, 12, 17, 19 e 21 - quebra de linha; não influencia o POST, apenas formata a informação do FORM.

Linhas 18 e 20 - tag html que representa uma espécie de menu de opções (representado pelo atributo type="radio") e possibilita que o usuário escolha entre dois ou mais valores, neste caso o sexo da pessoa ("Masculino" ou "Feminino"); participam do POST. O acesso a informação correta da escolha acontece pelo valor do atributo name, que pode ser usado em mais de um campo ao mesmo tempo.

Linha 22 - tag html que representa um botão passível de clique pelo usuário (representado pelo atributo type="submit") que envia o formulário.

Linha 23 - também representa um botão passível de clique, entretanto o atributo type="reset" limpa o conteúdo dos inputs do html FORM.


Integrando com a iVarejo

Agora que você já entendeu como um html FORM é criado e como as coisas funcionam dentro dele, sugiro a leitura da documentação de integração com a iVarejo via Pop-Up com Post/FORM. Você pode estar surpreso com o tamanho do formulário, mas não tenha medo! =)

As duas principais diferenças entre o nosso exemplo acima e o modelo de formulário da documentação são: a quantidade de campos que o usuário deve preencher e o valor do atributo action do FORM que aponta para o nosso ambiente de homologação

http://hml.ivarejo.com.br/ecommerce/enviodadospedido.aspx

Quando o usuário preenche o formulário e clica no botão de envio, as informações do formulário passam a fazer parte do corpo da entidade da mensagem de request e são enviadas. Quando a plataforma iVarejo recebe essa mensagem, realiza o processamento necessário e abre uma pop-up com o processo de pagamento no computador do seu cliente.

Assim que a compra for finalizada ou tenha sido cancelada por algum motivo, a iVarejo retorna o status da transação. Na documentação você pode ver como "receber" a resposta do pagamento utilizando a tecnologia ASP. Em breve, nós atualizaremos a documentação para exemplificar o recebimento da resposta em outras linguagens.


Espero que tenha gostado do assunto. Agora você já sabe com se intergrar à iVarejo utilizando o Pop-Up com POST/Form, mas caso tenha qualquer dúvida, basta entrar em contato conosco através dos canais disponibilizados!

No próximo post começaremos a falar sobre o XML para podermos falar depois sobre a integração com a iVarejo via POST/XML.




tags: #http, #protocolo, #request, #integracao,  #html, #w3c

Fontes:

http://www.w3.org/TR/html4/interact/forms.html

1-10 of 15