Upgrade to Pro — share decks privately, control downloads, hide ads and more …

WCPOA2019 - WordPress como um backend de seus aplicativos

WCPOA2019 - WordPress como um backend de seus aplicativos

Palestra WordPress como um backend de seus aplicativos apresentada no WordCamp Porto Alegre de 2019

Jackson F. de A. Mafra

June 08, 2019
Tweet

More Decks by Jackson F. de A. Mafra

Other Decks in Technology

Transcript

  1. WordPress como um
    backend de seus
    aplicativos

    View Slide

  2. Eu sou o Jackson Mafra
    Desenvolvedor há mais de 20 anos com background em
    projetos de e-commerce e mercado imobiliário, desde 2009
    com interesses focados para o desenvolvimento de
    interfaces móveis e aplicações corporativas.
    @jacksonfdam
    Olá!
    2

    View Slide

  3. Diferença entre
    Web Services e API
    Por que todos os tigres são gatos, mas nem todos os gatos são tigres.
    1
    3

    View Slide

  4. Web Services vs API
    4

    View Slide

  5. API (Application Programming
    Interface)
    É como uma interface entre dois programas diferentes de modo
    que eles possam se comunicar um com o outro.
    Ou seja, uma API é a forma que terceiros disponibilizam uma
    interface de modo que possamos consumir um determinado
    serviço deles sem nos preocuparmos com a implementação do
    mesmo.
    As API podem usar qualquer meio de comunicação para iniciar a
    interação entre as aplicações.
    Por exemplo, as chamadas de sistema (System Calls) são
    invocados usando interrupções da API do kernel Linux.
    5

    View Slide

  6. Web Services
    É uma interface projetada para se comunicar via rede.
    É uma API que usa obrigatoriamente a rede.
    Tipicamente, HTTP é o protocolo mais comumente usado para a
    comunicação.
    Web Services também usam SOAP, REST e XML-RPC como meio
    de comunicação.
    Ou seja, quando uma API precisa enviar dados através de rede,
    estamos falando de Web Services.
    6

    View Slide

  7. Resumindo
    ◉ Todos os Web Services são API. Mas nem todas as API são Web Service.
    ◉ Web Services podem não executar todas as tarefas que uma API
    normalmente realiza (ou pode realizar).
    ◉ Um serviço Web utiliza apenas três estilos de comunicação: SOAP, REST
    e XML-RPC enquanto que a API pode usar qualquer estilo de
    comunicação.
    ◉ Um Web Service sempre precisa de uma rede para o seu funcionamento
    enquanto uma API não precisa.
    ◉ Uma API facilita a interface direta com um aplicativo enquanto que um
    Web Service é uma aplicação.
    7

    View Slide

  8. CORS
    CORB e CORP.
    8

    View Slide


  9. Quem aí já teve problemas com
    CORS?
    Mais fácil perguntar quem nunca
    teve, né?
    9

    View Slide

  10. Cross-Origin Resource
    Sharing
    CORS é o acrônimo de Cross-Origin Resource Sharing, que por sua vez, é
    uma especificação que visa criar um ambiente lógico de segurança no que diz
    respeito ao modo que consumimos conteúdo da web via browsers.
    Mas além de CORS, existem algumas outras abordagens que adicionam
    camadas extras de segurança na forma em que o browser se comunica com
    os servidores.
    A proposta principal do CORS é que ao receber uma requisição do browser, o
    servidor responderá uma informação via HTTP header, e tal informação,
    definirá exatamente como o browser validará a origem da requisição.
    10

    View Slide

  11. Cross-Origin Resource
    Sharing
    Por exemplo, supondo que um servidor aceite requisições apenas do domínio
    meusite.com, o servidor precisará simplesmente responder suas requisições
    com o header Access-Control-Allow-Origin e o valor http://meusite.com para
    habilitar o CORS no browser com essa regra.
    11

    View Slide

  12. Cross-Origin Resource
    Sharing
    Há também a possibilidade de informar para o browser que qualquer origem
    pode acessar determinados recursos ou todos os recursos de um servidor. E
    para isso basta utilizar o valor * no header Access-Control-Allow-Origin
    globalmente ou em requisições específicas.
    12

    View Slide

  13. Cross-Origin Resource
    Sharing
    Recomendo o post "Política de Cross-Origin" da Ana Coimbra.
    Tem bastante informação sobre o assunto lá.
    13

    View Slide

  14. Cross-Origin Read Blocking
    Valida requisições do browser antes mesmo de serem requisitadas no
    servidor. Tudo isso utilizando o MIME type da requisição como regra de
    validação.
    Por exemplo, uma requisição do tipo style deve fornecer o MIME type
    text/css, caso contrário, será bloqueada.
    14

    View Slide

  15. Cross-Origin Read Blocking
    Para habilitar este recurso, o servidor deve enviar sempre o header
    X-Content-Type-Options com o valor nosniff.
    Essa proposta visa ajudar na segurança contra ataques maliciosos do tipo
    CSRF, Meltdown e Spectre.
    15

    View Slide

  16. Cross-Origin Resource Policy
    Ele é um complemento ao CORB e só funciona para requisições definidas
    como no-cors, ou seja, requisições explicitamente sem proteção garantida de
    CORS.
    16

    View Slide

  17. Cross-Origin Resource Policy
    Para habilitar esse cross-origin checker, o servidor deve enviar o header
    Cross-Origin-Resource-Policy com o valor same-origin ou same-site.
    17

    View Slide

  18. Cross-Origin Resource Policy
    Com este header declarado pelo servidor, o browser irá invalidar
    respectivamente requisições no-cors de domínios com origem ou esquema
    de url diferente da origem da requisição.
    E como a CORB, essa proposta também visa ajudar contra ataques maliciosos
    do tipo Meltdown e Spectre.
    18

    View Slide

  19. Resumindo
    Vale lembrar que estas soluções são efetivas, mas não perfeitas, pois acessos
    inesperados e maliciosos ao servidor também podem ser feito através de
    browsers antigos (inseguros) que não suportam CORS, CORB e/ou CORP e
    também via terminais.
    Sendo assim, seu servidor deve ser autossuficiente contra acessos
    indesejados.
    19

    View Slide

  20. WP-API
    REST API != WordPress APIs != API HTTP
    20

    View Slide

  21. APIs WordPress
    21

    View Slide

  22. WordPress APIs
    As APIs do WordPress representa a Interface de Programação de Aplicativos
    do WordPress.
    Podem ser separadas em várias seções / tópicos da API.
    Cada um abrange as funções envolvidas e uso de um determinado conjunto
    de funcionalidades.
    Juntos, eles formam o que pode ser chamado de WordPress API, que são as
    interfaces plugin / tema / add-on criadas por todo o projeto WordPress.
    22
    https://codex.wordpress.org/WordPress_APIs

    View Slide

  23. WordPress APIs
    ◉ Dashboard Widgets API
    ◉ Database API
    ◉ HTTP API
    ◉ REST API
    ◉ File Header API
    ◉ Filesystem API
    ◉ Metadata API
    ◉ Options API
    ◉ Plugin API
    ◉ Quicktags API
    23
    ◉ Rewrite API
    ◉ Settings API
    ◉ Shortcode API
    ◉ Theme Modification API
    ◉ Theme Customization API
    ◉ Transients API
    ◉ Widgets API
    https://codex.wordpress.org/WordPress_APIs

    View Slide

  24. API HTTP
    24

    View Slide

  25. API HTTP
    Dentro do PHP, existem muitas maneiras possíveis de enviar solicitações
    HTTP.
    Os exemplos incluem file_get_contents, fsockopen e cURL.
    Antes do WordPress 2.7, todos os desenvolvedores de plug-ins tinham sua
    própria implementação para enviar solicitações HTTP e receber a resposta, o
    que era um fardo adicional para eles, porque precisavam dar suporte
    posteriormente para mantê-los funcionando.
    25
    https://codex.wordpress.org/HTTP_API

    View Slide

  26. API HTTP
    A API HTTP do WordPress foi criada para padronizar uma única API que
    tratava de tudo o que era relacionado ao HTTP da maneira mais simples
    possível.
    A API HTTP suporta vários transportes HTTP ou implementações para atender
    diferentes ambientes e configurações de hospedagem.
    26
    https://codex.wordpress.org/HTTP_API

    View Slide

  27. API HTTP
    A API HTTP fornece uma interface unificada usando um punhado de funções
    auxiliares.
    HTTP é centrado em torno de métodos (às vezes chamados de verbos) e
    recursos.
    Os recursos definem o item em que você deseja realizar uma ação específica ,
    o método define o tipo de ação que deseja realizar.
    Um recurso é uma URL que aponta para um objeto na web, por exemplo,
    uma publicação. Há uma série de métodos , os mais importantes dos quais
    são GET, POST, PUT e DELETE.
    27
    https://codex.wordpress.org/HTTP_API

    View Slide

  28. API HTTP
    Existem quatro funções para fazer pedidos com:
    ◉ wp_remote_get()
    ◉ wp_remote_post()
    ◉ wp_remote_head()
    ◉ wp_remote_request()
    Estes são bastante auto-explicativos, o último wp_remote_request(), é uma
    função generalizada que você pode usar com qualquer verbo HTTP.
    28
    https://codex.wordpress.org/HTTP_API

    View Slide

  29. API HTTP
    Para recuperar as diferentes partes da resposta e também testar qualquer erro
    resultante, a API HTTP do WordPress fornece as seguintes funções auxiliares:
    ◉ wp_remote_retrieve_body () - Recupera apenas o corpo da resposta.
    ◉ wp_remote_retrieve_headers () - Retorna uma matriz de todos os
    cabeçalhos HTTP de resposta.
    ◉ wp_remote_retrieve_header () - Retorna o valor de um cabeçalho HTTP
    com base no nome fornecido.
    ◉ wp_remote_retrieve_response_code () - Retorna os códigos de status de
    resposta da solicitação HTTP.
    29
    https://codex.wordpress.org/HTTP_API

    View Slide

  30. API REST
    30

    View Slide

  31. REST API
    Ela foi essencialmente projetada para preencher a lacuna entre o núcleo PHP
    do WordPress e o JavaScript que muitos aplicativos da Web usam
    atualmente.
    A infraestrutura para a API REST do WordPress foi adicionada ao núcleo do
    WordPress na versão 4.4 (codinome “Clifford”) em dezembro de 2015.
    Você precisava de um plug-in para usar a API REST naquele momento.
    No entanto, o restante dessa API, os endpoints de conteúdo para serem
    exatos, foi adicionado ao núcleo do WordPress na versão 4.7 (codinome
    “Vaughan”) em dezembro de 2016, negando a necessidade do plugin WP
    REST API.
    31
    https://developer.wordpress.org/rest-api/

    View Slide

  32. WordPress roadmap
    32

    View Slide

  33. REST API
    Todo o seu conteúdo é disponibilizado em consultas rápidas de texto que são
    entregues via JSON, com ela você pode consultar o texto de um artigo, os
    links das imagens que ele carrega, autor, comentários, pode trabalhar com
    resultados de busca, tudo que você faz em seu painel pode ser
    disponibilizado para consultas remotas e integrações com outros sistemas.
    Tudo funciona através de chamadas como /wp-json/wp/v2/posts,
    /wp-json/wp/v2/users/4, /wp-json/wp/v2/posts?filter[s]=suporte, você
    pode consultar a documentação completa para mais parâmetros.
    33
    https://developer.wordpress.org/rest-api/

    View Slide


  34. Todo o seu conteúdo é
    disponibilizado em consultas
    rápidas de texto que são entregues
    via JSON
    34

    View Slide

  35. REST API
    Como uma API pode te ajudar? Usando o WP-API, desenvolvedores mobile
    poderão lidar com sites em WordPress como lidariam com qualquer serviço
    de Mobile Back End as a Service (MBaaS ou BaaS).
    Este ponto sozinho já é suficiente para habilitar um site em WordPress como
    uma possibilidade para servir de backend para aplicações mobile nativas e
    serve de fundação para todos os tipos de integrações no futuro.
    35
    https://developer.wordpress.org/rest-api/

    View Slide


  36. Ao expôr meu conteúdo, o WP-API não
    oferece nenhum risco à segurança?
    Não.
    Não propriamente por conta da
    WP-API.
    36

    View Slide

  37. REST API
    A informação que a API fornece é, naturalmente, o que um site WordPress
    dispõe por padrão publicamente.
    A única diferença entre o front-end de um site e o WP-API é a forma como as
    informações são apresentadas.
    Por padrão não é possível, sem autenticação, apagar, atualizar ou criar nada –
    apenas ler o conteúdo (requisição GET).
    Claro que novas funcionalidades expõem novos riscos.
    Porém, por ora, nenhuma vulnerabilidade foi encontrada e manter seu
    WordPress atualizado é um método simples e confiável de se manter seguro.
    37
    https://developer.wordpress.org/rest-api/

    View Slide

  38. REST API
    Para começar a usar a API REST do WordPress, vamos detalhar alguns dos
    principais conceitos e termos associados à API:
    ◉ Routes/Endpoints
    ◉ Requests
    ◉ Responses
    ◉ Schema
    ◉ Controller Classes
    38
    https://developer.wordpress.org/rest-api/

    View Slide

  39. REST API
    Routes & Endpoints
    Uma rota, no contexto da API REST do WordPress, é um URI que pode ser
    mapeado para diferentes métodos HTTP.
    O mapeamento de um método HTTP individual para uma rota é conhecido
    como um “endpoint”. Se fizermos uma solicitação GET para/wp-json/ ,
    obteremos uma resposta JSON mostrando-nos quais rotas estão disponíveis
    e, dentro de cada rota, quais terminais estão disponíveis. /wp-json/ é uma
    rota em si e quando uma solicitação GET é feita, ela corresponde ao terminal
    que exibe o que é conhecido como o índice da API REST do WordPress.
    39
    https://developer.wordpress.org/rest-api/

    View Slide

  40. 40
    REST API
    https://developer.wordpress.org/rest-api/

    View Slide

  41. Se você estiver usando permalinks (urls amigáveis), passe a rota da API REST
    como um parâmetro de string de consulta.
    A rota /wp-json/ seria /?rest_route=/ .
    41

    View Slide

  42. REST API
    Requests
    Uma das classes principais na infraestrutura da API REST do WordPress é
    WP_REST_Request .
    Essa classe é usada para armazenar e recuperar informações para a
    solicitação atual; Os requests podem ser enviados remotamente via HTTP,
    mas também podem ser feitos internamente a partir do PHP com o
    WordPress.
    Os objetos WP_REST_Request são gerados automaticamente para você
    sempre que você faz uma solicitação HTTP para uma rota registrada.
    42
    https://developer.wordpress.org/rest-api/

    View Slide

  43. REST API
    Responses
    Respostas são os dados que você recebe da API.
    A classe WP_REST_Response fornece uma maneira de interagir com os dados
    de resposta retornados pelos nós de extremidade.
    As respostas podem retornar os dados desejados e também podem ser
    usadas para retornar erros.
    43
    https://developer.wordpress.org/rest-api/

    View Slide

  44. REST API
    Schema
    Cada endpoint requer e fornece estruturas de dados ligeiramente diferentes, e
    essas estruturas são definidas no esquema da API.
    O esquema estrutura os dados da API e fornece uma lista abrangente de
    todas as propriedades que a API pode retornar e parâmetros de entrada que
    pode aceitar.
    O esquema também fornece benefícios de segurança para a API, pois nos
    permite validar as solicitações feitas à API.
    44
    https://developer.wordpress.org/rest-api/

    View Slide

  45. REST API
    Controller Classes
    Como você pode ver, a API REST do WordPress tem muitas partes móveis que
    precisam trabalhar juntas.
    As classes do controlador reúnem todos esses elementos em um único lugar.
    Com uma classe de controlador, você pode gerenciar o registro de rotas e
    terminais, manipular solicitações, utilizar o esquema e gerar respostas da API.
    45
    https://developer.wordpress.org/rest-api/

    View Slide

  46. Pagination
    Qualquer resposta da API que
    contenha vários recursos
    suporta vários parâmetros de
    consulta comuns para manipular
    a paginação pelos dados da
    resposta
    Autenticação
    A autenticação de cookie é o único
    mecanismo de autenticação
    disponível nativamente no
    WordPress, os plug-ins podem ser
    adicionados para oferecer suporte a
    modos alternativos de autenticação
    que funcionarão a partir de
    aplicativos remotos.
    46
    REST API
    https://developer.wordpress.org/rest-api/

    View Slide

  47. REST API
    FAQ - Posso desativar a API REST?
    Você não deve desabilitar a API REST, pois isso quebrará a funcionalidade
    Admin do WordPress que depende da API estar ativa.
    No entanto, você pode usar um filtro para exigir que os consumidores da API
    sejam autenticados, o que efetivamente impede o acesso externo anônimo.
    47
    https://developer.wordpress.org/rest-api/

    View Slide

  48. WordPress Plugins
    ◉ Advanced Custom Fields
    ◉ ACF to REST API
    ◉ JWT Authentication for WP REST API
    ◉ Custom Post Type UI
    ◉ Basic-Auth
    48

    View Slide

  49. Repositório utilizado:
    https://github.com/jacksonfdam/wp-baas
    49

    View Slide

  50. 50

    View Slide

  51. Alguma pergunta ?
    Onde me chamar:
    ◉ @jacksonfdam
    ◉ jacksonfdam[at]gmail.com
    Obrigado!
    51

    View Slide