No Geektimes, geralmente encontro e gosto de ler posts da série DIY. Tendo decidido fazer uma pequena contribuição ao tesouro de uma valiosa experiência reunida aqui, descreverei em detalhes o processo de criação de um cliente para a Web com base nos servidores de Linha.
O sistema de vigilância de linha fornece uma API aberta, e os desenvolvedores dizem que é possível escrever seu próprio cliente com base nele para visualizar o arquivo de vídeo e as câmeras online. Além disso, se desejado, você pode implementar funções como adicionar eventos ao arquivo, sobrepor o OSD na parte superior do vídeo. Uma descrição de todos os recursos é apresentada na
especificação no site oficial .
Este artigo é um exemplo real de como eu, um usuário com conhecimento inicial de JS, HTML, escrevi meu próprio aplicativo que implementa os princípios básicos de trabalho com servidores de linha por meio do servidor da web interno.
Dados de entrada
O autor é iniciante no desenvolvimento de um cliente HTML e está envolvido no desenvolvimento do sistema de vigilância por vídeo Line.
Nível de conhecimento de JS, HTML - inicial.
A tarefa é escrever um cliente HTML para trabalhar com dispositivos baseados no software Line, usando a especificação do site.
Vou revelar a principal intriga imediatamente - cheguei a duas conclusões:
- A especificação é real, é descrita com bastante clareza, você pode escrever um cliente usando C ++, PHP.
- Você não pode gravar um cliente HTML completo usando apenas JS - somente monitoramento online de acordo com a especificação anterior ao RPC.
A primeira conclusão é bastante lógica, dado o grande número de integrações com programas de terceiros. Todos eles estão descritos no site: existem
sistemas de controle de acesso ,
peso ,
sistemas POS , programas para
determinar o número de carros e
1C .
A segunda conclusão é mais interessante, considere-a abaixo.
Por que você não pode criar um cliente completo em HTML + JS?
Resposta: solicitações entre domínios.
No momento, o servidor da Web da linha é limitado e, simplesmente copiando o código para a pasta www, o acesso não pode ser obtido. No entanto, os desenvolvedores prometem que, na nova versão para Linux e na "Linha 8.0", o servidor da Web funcione como padrão: no caso de uma solicitação, se houver um arquivo, ele será devolvido.
Agora crie um novo projeto e comece a codificar. Como todos os novatos em programação para a Web, especificando que o servidor "Lines" responde "*" no cabeçalho Access-Control-Allow-Origin, comecei a trabalhar duro no código, verificando o resultado no Firefox 57.0.4 (64 bits). Solicitações para o servidor foram enviadas por XMLHttpRequest.
Inicialmente, seria útil estudar as informações sobre
este recurso . Tudo é descrito em grandes detalhes lá, mas eu realmente queria concluir a tarefa rapidamente. E, infelizmente, devido à falta de informações, meio dia foi perdido ao bater a cabeça na parede da política de segurança dos navegadores modernos.
No momento da redação deste artigo, os quatro principais navegadores modernos não permitem ler os cabeçalhos recebidos do servidor. De acordo com a especificação, é necessário implementar a autenticação Digest, o que é impossível sem cabeçalhos.
No final do primeiro dia, percebi que, sem adicionar o processamento de OPTIONS ao servidor da Web da linha, nada funcionaria, pois para solicitações com um método "difícil" ou cabeçalhos especiais, o navegador faz uma pré-solicitação de OPTIONS, indicando-as no Método de Controle de Acesso-Controle-Pedido e cabeçalhos de solicitação de controle de acesso. Então comecei a procurar outras opções de autorização, mas o Basic ou Digest real não decolou.
Um método alternativo já foi descrito na especificação, mas permaneceu passando algum tempo correspondendo ao departamento de programa de "Linhas". Como essas dificuldades surgem não pela primeira vez, já existe uma muleta para autorização, e isso é mencionado na especificação:
Nos clientes em que é impossível autorizar a solicitação usando meios padrão (HTTP Digest / Autenticação Básica), o cabeçalho da Autorização pode ser enviado usando um dos parâmetros da solicitação, por exemplo
/kfd3ado1sdrms/streaming/main.flv?authorization=Basic%20d2ViOg==
Depois de todas as manipulações, a solicitação entre domínios padrão começou a ser executada corretamente! Também é necessário adicionar o cabeçalho Accept com o tipo correto à solicitação - eu decidi usar o JSON.
Código da solicitação:
function get_request_url(method,current_server_data, resource, additional){ var request = current_server_data.server_ip + ':' +current_server_data.port +resource+'?authorization=Basic '+ utf8_to_b64(current_server_data.user+':'+current_server_data.password); if (additional != '' && typeof additional != "undefined") { request += '&' + additional; } return request; } function http_request_of_resource (server_index , resource, auth_attempt) { var request = get_request_url('GET', servers_array[server_index], resource,''); var req_ = new XMLHttpRequest(); req_.open('GET', 'http://'+ request, true);
Alteramos o recurso para o que precisamos de acordo com a especificação e obtemos esses ou aqueles dados. A variável adicional contém parâmetros adicionais para a solicitação, se necessário. Com isso, o desenvolvimento da primeira metade da especificação, a saber, o recebimento / envio de dados de texto via solicitações GET, pode ser considerado fechado.
Além disso, deparei-me com o fato de a tag IMG no IE não reproduzir o fluxo MJPEG, e você precisa implementar independentemente a atualização de imagens das câmeras. O código está aberto, pode ser visualizado e alterado, se desejado. Na implementação atual, a reprodução simultânea de no máximo seis fluxos MJPEG está disponível; portanto, você terá que fazer o trabalho com uma exibição que mostre mais câmeras. Tudo isso está no
exemplo , se você desejar, poderá encontrar e entender, mas se tiver dúvidas, não deixe de perguntar nos comentários.
Especificação RPC
Somos convidados a enviar e receber dados em JSON (versão do servidor "Linhas 7.1.1" e superior) ou MessagePack (versão "Linha 7.0" e superior). É mencionado que o MessagePack pesa menos e funciona mais rápido, mas, para ser honesto, eu escolheria o JSON (ele já está embutido no JS), se não fosse uma coisa, mas na especificação: receber quadros do arquivamento é possível apenas no MessagePack. Eu tive que ir ao
site oficial e baixar o arquivo JS, que possui os métodos de codificação e decodificação.
A função de envio de pedidos está pronta! Mas é muito cedo para comemorar a vitória: quando você tenta alterar o cabeçalho da solicitação do tipo Conteúdo, o navegador jura e não envia dados para o servidor. O fato é que o servidor de Linhas analisa esse campo e o analisa, dependendo do tipo. Eu não poderia fazer isso sozinho.
Enviei uma solicitação ao departamento de programa e, após discussão, eles me adicionaram uma muleta, como no caso de autorização, - o tipo de Conteúdo será transmitido na solicitação de URL:
function rpc_request_of_resource (current_server_data , rpc_method, rpc_request) { var request = get_request_url('POST', current_server_data, '/rpc','');
Essa alteração funcionará com a versão "Linha 7.4.1" e superior. Para todos os servidores abaixo desta versão, o trabalho com o recurso / rpc não estará disponível.
No final, quero agradecer a todos os clientes que nos enviaram perguntas / desejos relacionados à implementação de aplicativos com base em nossa API. Graças a você, foi realizado um estudo, no âmbito do qual algumas deficiências foram identificadas e corrigidas.
O exemplo descrito neste artigo gradualmente se transformará em um cliente HTML completo para o Lines. Todo o código será legível, você pode alterá-lo ou usá-lo como base para criar suas próprias soluções. A API, com o tempo, será preenchida com ainda mais recursos, sobre os quais iremos definitivamente informar.