Integrating WeChat Authentication with Guest WiFi Captive Portals
Este guia explica como integrar a autenticação WeChat OAuth 2.0 em Captive Portals de WiFi para visitantes de empresas. O material abrange os requisitos de registro em duas plataformas, a seleção de escopo para captura de dados proprietários (first-party), a aplicação de regras de rede via RADIUS Change of Authorization e a conformidade com o GDPR e a PIPL da China. Operadores de locais nos setores de hotelaria, varejo e eventos encontrarão etapas de implementação concretas, estudos de caso reais e orientações de segurança para implantar o login via WeChat no WiFi para visitantes em escala.
Ouça este guia
Ver transcrição do podcast
Resumo executivo
Quando um visitante chinês se conecta à rede da sua empresa e se depara com um Captive Portal que oferece apenas e-mail, Facebook ou um código de voucher, você introduz um atrito imediato. O WeChat possui 1,38 bilhão de usuários ativos mensais, de acordo com os dados de 2024 da Tencent. Integrar recursos de login do WeChat com o guest WiFi não é apenas uma conveniência de hospitalidade - é um requisito técnico para capturar dados primários (first-party data) dessa demografia sem atritos.
Este guia detalha a arquitetura técnica para integrar a autenticação WeChat OAuth 2.0 em Captive Portals. Ele explica o registro em plataforma dupla necessário para suportar tanto os navegadores móveis padrão quanto o navegador interno do WeChat, avalia os prós e contras entre os escopos snsapi_base e snsapi_userinfo para coleta de dados e descreve como impor o acesso à rede usando RADIUS Change of Authorization (CoA) ou desvio de autenticação MAC (MAC authentication bypass). Também abrange as configurações de segurança e os mandatos de conformidade - GDPR e a PIPL da China - necessários para implantar essa solução em escala nas infraestruturas Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.
Análise técnica detalhada: Arquitetura WeChat OAuth 2.0
Um Captive Portal intercepta o tráfego HTTP de um dispositivo não autenticado e o redireciona para uma página de login hospedada em um servidor de portal. A adição da autenticação do WeChat insere um provedor de identidade de terceiros nesse fluxo usando o protocolo OAuth 2.0 - o mesmo padrão utilizado pelo Google, Microsoft Entra ID e Okta para identidade federada.
A sequência de autenticação opera da seguinte forma. O visitante conecta-se ao SSID. O ponto de acesso ou controlador sem fio detecta a sessão não autenticada e redireciona o tráfego HTTP para a URL do Captive Portal. O visitante seleciona o login do WeChat na página do portal. O servidor do portal redireciona o navegador para o endpoint de autorização do WeChat em open.weixin.qq.com, passando o AppID, a URI de redirecionamento, o tipo de resposta como code e o escopo solicitado. O WeChat lida com a autenticação em seus próprios servidores. Se o visitante utilizar o navegador interno do WeChat com o escopo snsapi_base, a autenticação é silenciosa - nenhuma solicitação de consentimento é exibida. Se utilizar snsapi_userinfo, o WeChat apresenta uma tela de consentimento. O WeChat redireciona de volta para a URI de redirecionamento do portal com um código de autorização temporário. O servidor do portal troca esse código por um token de acesso chamando api.weixin.qq.com/sns/oauth2/access_token, passando o AppID, AppSecret, o código e o tipo de concessão como authorization_code. O WeChat retorna um token de acesso, um token de atualização, o OpenID do usuário e o escopo concedido. Se o snsapi_userinfo foi concedido, o servidor faz uma segunda chamada de API para recuperar o apelido, avatar, gênero e cidade do usuário.
O requisito de registro em dupla plataforma
A maioria das implementações falha na etapa de registro. O WeChat opera duas plataformas de desenvolvedores separadas, e implantações corporativas normalmente exigem ambas.
| Plataforma | URL | Tipo de conta necessário | Escopo suportado | Contexto do navegador |
|---|---|---|---|---|
| Official Accounts Platform | mp.weixin.qq.com | Service Account | snsapi_base, snsapi_userinfo | Navegador interno do WeChat |
| Open Platform | open.weixin.qq.com | Website Application | snsapi_login | Navegador móvel padrão |
Para visitantes que acessam o portal dentro do navegador interno do WeChat, você precisa de uma Service Account na Official Accounts Platform. Uma Subscription Account não funcionará - ela não possui permissões de autorização de página web OAuth. Para visitantes que acessam o portal a partir do Chrome no Android ou Safari no iOS, você precisa de uma Website Application na Open Platform, que usa o escopo snsapi_login e apresenta um código QR para o usuário escanear.
Na prática, a maioria das implantações em locais físicos utiliza ambos. Um hóspede em um hotel pode abrir o portal no Chrome, ver um código QR, escaneá-lo com o WeChat e se autenticar. Ou pode seguir um link dentro do próprio WeChat, cair no navegador interno e se autenticar silenciosamente com snsapi_base.
Seleção de escopo: captura de dados vs. fricção
O escopo solicitado determina quais dados você coleta e a fricção que o visitante experimenta. Este é um ponto de decisão real com implicações de conformidade.
snsapi_base retorna apenas o OpenID - um identificador exclusivo para esse usuário dentro de sua Conta Oficial. Não requer solicitação de consentimento do usuário. A autenticação é invisível para o visitante. Use isso para visitantes recorrentes cujos perfis você já possui, ou quando você prioriza o acesso sem atritos. Sob os princípios de minimização de dados do GDPR e PIPL, o snsapi_base é mais fácil de justificar.
snsapi_userinfo retorna o OpenID mais o apelido do usuário, foto de perfil, gênero e cidade. Ele exige uma tela de consentimento explícito. Use isso para o registro de visitantes de primeira viagem onde você precisa criar um perfil, combinado com uma camada de consentimento em conformidade em sua página do Captive Portal.
UnionID para implantações em múltiplas propriedades
O OpenID é exclusivo para a combinação de um usuário e uma Conta Oficial específica. Um grupo de hotéis com 20 propriedades, cada uma com sua própria Conta Oficial, verá 20 OpenIDs diferentes para o mesmo visitante. O UnionID resolve isso. É um identificador único que representa um usuário em todas as Contas Oficiais e aplicativos vinculados à mesma conta da Open Platform. Vincule suas Contas Oficiais à sua conta da Open Platform, e o UnionID será retornado na resposta OAuth. Essa é a base do reconhecimento de visitantes entre propriedades.
Guia de implementação
Mecanismos de aplicação de rede
Obter um token OAuth prova a identidade. Isso não abre a rede. Você deve sinalizar ao controlador para permitir o tráfego.
RADIUS Change of Authorization (CoA), definido na RFC 3576, é a abordagem empresarial recomendada. Após o OAuth bem-sucedido, o servidor do portal envia uma solicitação de CoA para o controlador de rede. O controlador move o dispositivo da VLAN de pré-autenticação para a VLAN de visitantes. Isso funciona com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.
MAC Authentication Bypass (MAB) registra o endereço MAC do dispositivo como um cliente autorizado no banco de dados RADIUS. O controlador permite o acesso com base nesse MAC. O MAB é mais simples de implementar, mas não é confiável: dispositivos iOS e Android modernos randomizam endereços MAC por padrão, quebrando a associação da sessão na reconexão.
A plataforma de Guest WiFi da Purple automatiza essa tradução. Após a conclusão do WeChat OAuth, a sobreposição em nuvem da Purple envia o sinal de CoA ou MAB apropriado para o hardware subjacente, eliminando a configuração manual de VLAN.
Configuração de segurança
Três configurações são inegociáveis.
- Proteja o AppSecret. O
AppSecretnunca deve aparecer no JavaScript do lado do cliente. Ele deve permanecer no seu servidor. Se exposto, invasores podem se passar pelo seu aplicativo e chamar APIs do WeChat em seu nome. - Implemente proteção CSRF. Gere um valor de
statecriptograficamente aleatório, armazene-o na sessão do usuário e valide-o quando o WeChat redirecionar de volta. Isso evita ataques de falsificação de solicitação entre sites, conforme definido na RFC 6749. - Registre todas as variantes de URI de redirecionamento. O WeChat valida a URI de redirecionamento contra o seu domínio registrado. Registre cada subdomínio e variante de caminho que você utiliza, incluindo ambientes de homologação, para evitar o erro 40029 (código inválido).
Detecção de navegador in-app
O navegador in-app do WeChat define uma string de user agent contendo MicroMessenger. Seu Captive Portal deve detectar essa string e rotear adequadamente: fluxo de Conta Oficial para navegador in-app, fluxo de código QR de Plataforma Aberta para navegadores padrão. Falhas nessa detecção resultam em experiências quebradas ou erros de autenticação.
Melhores práticas e conformidade
Conformidade com o GDPR
Se você atende visitantes europeus ou opera na Europa, o GDPR se aplica aos dados coletados via WeChat OAuth. Você deve estabelecer uma base legal para o processamento — geralmente consentimento ou legítimo interesse. Você deve fornecer um aviso de privacidade claro no Captive Portal antes da autenticação. Você deve atender às solicitações de acesso e exclusão dos titulares dos dados. Para um framework de conformidade detalhado, consulte The Compliance Playbook: GDPR and Guest WiFi Data Privacy .
Conformidade com a PIPL
A Lei de Proteção de Informações Pessoais da China (PIPL) se aplica quando você processa dados pessoais de cidadãos chineses. Assim como o GDPR, a PIPL exige limitação clara de finalidade, minimização de dados e uma base legal documentada. O snsapi_base é mais fácil de justificar sob a minimização de dados do que o snsapi_userinfo. O que quer que você colete, documente sua base legal e período de retenção antes de entrar em produção.
Segmentação de rede
Isole o tráfego de WiFi de convidados da sua rede corporativa usando segmentação por VLAN. Os convidados autenticados via WeChat devem ser direcionados para uma VLAN de convidados dedicada apenas com acesso à internet — sem acesso aos sistemas internos. Isso se alinha com os requisitos do PCI DSS para isolamento do ambiente de dados de portadores de cartão e com as práticas gerais de segurança corporativa. Para saber mais sobre arquitetura de segmentação, consulte Bandwidth Management: A Practical Guide for 2026 .
Autenticação de fallback
Se a API do WeChat estiver indisponível, seu portal deve redirecionar para um método de login alternativo. Não deixe os convidados com uma tela em branco. Um fallback para e-mail ou SMS garante a continuidade. Isso é particularmente importante para estabelecimentos em ambientes de Transport e Healthcare , onde a conectividade é uma obrigação do serviço.
Casos de estudo do mundo real
Hospitalidade: grupo de hotéis de luxo
Um hotel de luxo de 400 quartos em Londres atende a uma proporção significativa de hóspedes da China continental. O Captive Portal existente exigia um endereço de e-mail e verificação por SMS. Os números de celular chineses frequentemente falham em receber SMS de provedores europeus, e muitos hóspedes não têm um e-mail local configurado em seus dispositivos. O resultado foi uma taxa de abandono de 60% no portal.
O hotel registrou uma Conta de Serviço na Official Accounts Platform e um aplicativo de site na Open Platform. O portal detecta o user agent MicroMessenger e aciona o snsapi_base para usuários de navegadores integrados (in-app) - conectando-os em menos de três segundos sem tela de consentimento. Os hóspedes que chegam via Chrome ou Safari veem um QR code. Em estadias subsequentes, o mesmo OpenID é reconhecido e o hóspede é autenticado silenciosamente. O CRM do hotel registra o retorno do visitante, permitindo comunicações pré-chegada direcionadas. Para saber mais sobre a implantação de WiFi em ambientes de hospitalidade, consulte Hospitalidade .
Varejo: análise de shopping centers
Um grande shopping center quer capturar dados demográficos de compradores chineses para orientar o mix de lojistas e as decisões de marketing. Eles precisam de cidade de origem, gênero e frequência de visitas. O snsapi_base é insuficiente - eles precisam do snsapi_userinfo. O portal solicita o escopo completo de userinfo. O hóspede vê uma tela de consentimento do WeChat e toca em Permitir. A plataforma de análise do shopping, integrada ao WiFi Analytics da Purple, recebe um fluxo de dados demográficos verificados. Nas tardes de sábado, 40% dos usuários de WiFi têm origem em uma região específica. Esses dados informam diretamente quais marcas abordar para eventos pop-up. Para mais informações sobre implantações de WiFi no varejo, consulte Varejo .
Resolução de problemas e mitigação de riscos
Os cinco modos de falha mais comuns em implantações de Captive Portal com WeChat OAuth são os seguintes:
Incompatibilidade de URI de redirecionamento (erro 40029). O WeChat valida o URI de redirecionamento em relação ao domínio registrado. Qualquer incompatibilidade de subdomínio, caminho ou protocolo resultará na falha da troca de código. Registre todas as variantes, incluindo ambientes de homologação.
Exposição do AppSecret. Incorporar o AppSecret no código do lado do cliente é o erro de segurança mais grave de todos. Mova toda a lógica de troca de tokens para o servidor.
Falta de proteção contra CSRF. Omitir a validação do parâmetro state deixa o portal vulnerável a ataques de falsificação de solicitação entre sites. Gere um valor criptograficamente aleatório por sessão e valide-o no retorno de chamada (callback).
Falha na detecção do navegador integrado (in-app). Não detectar o MicroMessenger no user agent significa que os usuários do navegador integrado receberão o fluxo de OAuth incorreto, gerando erros.
A randomização do endereço MAC interrompe as sessões MAB. Os sistemas operacionais móveis modernos randomizam os endereços MAC. Os visitantes que utilizam a imposição baseada em MAB perderão a sessão ao se reconectarem. Atualize para RADIUS CoA para um gerenciamento de sessão confiável. Para orientações sobre configuração segura de WiFi, consulte What Is Secure WiFi: Essential Guide for Business 2026 .
ROI e impacto nos negócios
A implementação da funcionalidade de login do WeChat no guest WiFi gera três impactos mensuráveis.
Aumento nas taxas de autenticação. A eliminação do ponto de falha na verificação por SMS e da exigência de inserção de e-mail aumenta a porcentagem de visitantes chineses que se conectam com sucesso. Uma taxa de abandono de 60% é uma linha de base realista para portais sem suporte ao WeChat.
Qualidade de dados primários (first-party). Os perfis autenticados via WeChat incluem um OpenID verificado e, com o snsapi_userinfo, atributos demográficos obtidos diretamente da plataforma social. Esses dados alimentam plataformas de análise para impulsionar o marketing direcionado sem depender de cookies de terceiros.
Redução nos custos de suporte. O login sem atrito reduz as chamadas de suporte para a recepção e TI de hóspedes internacionais que tentam resolver problemas de conexão.
A Purple opera em mais de 80.000 locais e processou 440 milhões de logins em 2024 (dados internos da Purple). A plataforma possui certificação ISO 27001, está em conformidade com a GDPR e CCPA, e mantém 99,999% de uptime. Para estabelecimentos de Varejo e Hospitalidade , a autenticação do WeChat transforma a rede de um centro de custo em um canal confiável de aquisição de dados primários.
Definições principais
Captive Portal
Uma página web que intercepta o tráfego HTTP de um dispositivo não autenticado e exige que o usuário interaja com ela antes que o acesso à rede seja concedido.
A interface principal onde a opção de login do WeChat é apresentada ao visitante. O servidor do portal hospeda esta página e orquestra o fluxo de OAuth.
OAuth 2.0
Um protocolo de autorização padrão de mercado (RFC 6749) que permite que um aplicativo de terceiros obtenha acesso limitado a um serviço HTTP em nome de um usuário.
O protocolo subjacente que o WeChat usa para passar tokens de autenticação para o servidor do portal sem expor as credenciais do usuário. O mesmo protocolo usado pelo Microsoft Entra ID, Okta e Google Workspace.
OpenID
Um identificador alfanumérico exclusivo atribuído a um usuário específico do WeChat para uma Conta Oficial específica.
Usado como a chave primária para identificar visitantes que retornam no banco de dados de analytics de WiFi. Muda por Conta Oficial - use UnionID para reconhecimento entre diferentes propriedades.
UnionID
Um identificador único do WeChat que representa um usuário em todas as Contas Oficiais e aplicativos vinculados à mesma conta da Open Platform.
Essencial para grupos hoteleiros, redes de varejo e operadores de estádios com múltiplos locais que precisam reconhecer o mesmo visitante em todo o seu patrimônio.
RADIUS CoA (Change of Authorization)
Uma extensão para o protocolo RADIUS (RFC 3576) que permite que um servidor RADIUS altere dinamicamente os atributos de autorização de uma sessão ativa.
O método seguro usado para mover o dispositivo de um visitante de uma VLAN de pré-autenticação isolada para a VLAN de internet ativa após o login bem-sucedido no WeChat. Suportado por Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.
snsapi_base
Um escopo do WeChat OAuth que retorna apenas o OpenID do usuário e não requer nenhuma solicitação de consentimento do usuário.
O escopo recomendado para a reautenticação de visitantes que retornam. Mais fácil de justificar sob os princípios de minimização de dados do GDPR e da PIPL.
snsapi_userinfo
Um escopo do WeChat OAuth que retorna o OpenID, apelido, avatar, gênero e cidade do usuário, e exige uma tela de consentimento explícito.
Usado para o registro de visitantes pela primeira vez, onde dados demográficos são necessários para analytics. Requer base legal documentada sob o GDPR e a PIPL.
PIPL (Personal Information Protection Law)
A legislação abrangente de privacidade de dados da China, em vigor desde novembro de 2021, que regulamenta o processamento de informações pessoais de pessoas físicas localizadas na China.
Aplica-se quando os estabelecimentos processam dados de cidadãos chineses via WeChat OAuth. Requer consentimento claro, limitação de finalidade, minimização de dados e um mecanismo de exclusão.
AppSecret
Uma chave criptográfica confidencial emitida pelo WeChat durante o registro do aplicativo, usada para autenticar chamadas de API do servidor do portal.
Deve ser armazenado exclusivamente no lado do servidor. A exposição no JavaScript do lado do cliente permite que invasores se passem pelo aplicativo e façam chamadas de APIs do WeChat de forma maliciosa.
Exemplos práticos
Um hotel de luxo com 400 quartos em Londres tem uma taxa de abandono do portal de 60% entre hóspedes da China continental. O portal atual exige verificação por e-mail e SMS. O Diretor de TI precisa implementar a autenticação do WeChat, mantendo a conformidade com o GDPR e a segurança da rede.
Etapa 1: Registre uma Conta de Serviço na WeChat Official Accounts Platform (mp.weixin.qq.com) e um Aplicativo Web na WeChat Open Platform (open.weixin.qq.com). Etapa 2: Configure o portal para detectar a string de user agent do MicroMessenger. Se detectada, acione o fluxo OAuth snsapi_base para autenticação silenciosa. Se não for detectada, apresente o fluxo de código QR. Etapa 3: Adicione um aviso de privacidade em conformidade com o GDPR e uma caixa de seleção de consentimento à página do portal antes que o botão de login do WeChat fique ativo. O aviso deve indicar: dados coletados (apenas OpenID), finalidade (acesso ao WiFi de visitantes e reconhecimento de visitas de retorno) e período de retenção. Etapa 4: Após a troca bem-sucedida do token OAuth, o servidor do portal emite uma solicitação RADIUS CoA para o controlador Cisco Meraki, movendo o dispositivo do visitante da VLAN pré-autenticação para a VLAN segmentada de visitantes. Etapa 5: Armazene o OpenID associado ao endereço MAC do dispositivo no banco de dados de visitantes. Em visitas subsequentes, o OpenID de retorno aciona a reautenticação silenciosa.
Um shopping center deseja capturar dados de gênero e cidade de compradores chineses por meio do WiFi de visitantes para alimentar sua plataforma de análise. Atualmente, eles usam o MAC Authentication Bypass em seu portal existente executado em hardware HPE Aruba.
Etapa 1: Registre uma Conta de Serviço na WeChat Official Accounts Platform. Etapa 2: Configure o portal para usar o escopo snsapi_userinfo para recuperar gênero e cidade. Etapa 3: Adicione uma tela de consentimento clara explicando a troca de valor: WiFi gratuito em troca de acesso aos dados do perfil. O consentimento deve ser explícito e detalhado sob o GDPR e a PIPL. Etapa 4: Após a autenticação, o servidor do portal registra o endereço MAC do dispositivo no banco de dados RADIUS. O controlador HPE Aruba permite o acesso via MAB. Etapa 5: Documente a base jurídica (consentimento), a finalidade (análise do local e marketing) e o período de retenção (24 meses) em um registro de processamento de dados. Disponibilize um mecanismo de exclusão de dados.
Questões práticas
Q1. Você está implantando um Captive Portal em um estádio. Você deseja que os portadores de ingressos de temporada que já se autenticaram anteriormente se conectem automaticamente, sem visualizar uma tela de login nas visitas subsequentes. Qual escopo de OAuth do WeChat você deve implementar para o fluxo de reautenticação e por quê?
Dica: Considere qual escopo permite a autenticação silenciosa sem solicitar o consentimento do usuário a cada visita.
Ver resposta modelo
Use snsapi_base. Este escopo retorna apenas o OpenID do usuário e não exige solicitação de consentimento, permitindo a reautenticação silenciosa. Na primeira visita, você armazena o OpenID no perfil do torcedor. Nas visitas subsequentes, o portal detecta o OpenID de retorno via snsapi_base, confirma a correspondência e emite um RADIUS CoA para liberar o acesso - tudo sem que o torcedor veja uma tela de login. Isso também se alinha aos princípios de minimização de dados do GDPR, pois você não está coletando dados adicionais além do necessário para a função de autenticação.
Q2. Durante os testes, seu portal redireciona com sucesso para o WeChat, o usuário concede o consentimento e o WeChat redireciona de volta para o seu portal. No entanto, os logs do servidor do portal mostram o erro de OAuth 40029 (código inválido). Qual é o erro de configuração mais provável e como você o resolve?
Dica: O WeChat valida rigorosamente o destino para o qual envia o código de autorização em relação a uma lista registrada.
Ver resposta modelo
A causa mais provável é uma divergência na URI de redirecionamento. O WeChat valida a URI de redirecionamento na solicitação de OAuth em relação ao domínio autorizado registrado na plataforma. Se o servidor do portal usar um subdomínio diferente, um caminho diferente ou HTTP em vez de HTTPS, a troca de código falhará com o erro 40029. Resolução: acesse a plataforma de desenvolvedores do WeChat, navegue até as configurações de Conta de Serviço ou Aplicativo Web e adicione todas as variantes de URI de redirecionamento que você utiliza - incluindo subdomínios de homologação, caminhos diferentes e versões HTTPS. Certifique-se de que o parâmetro redirect_uri em sua solicitação de OAuth corresponda exatamente a uma das URIs registradas, incluindo a codificação de URL.
Q3. Um gerente de TI propõe incorporar o AppSecret do WeChat no JavaScript de front-end do Captive Portal para acelerar o processo de troca de tokens diretamente do navegador do cliente. Por que você deve rejeitar esta proposta e qual é a arquitetura correta?
Dica: Considere as implicações de segurança de expor chaves criptográficas em códigos acessíveis publicamente.
Ver resposta modelo
Rejeite esta proposta. O AppSecret é uma chave criptográfica confidencial. Incorporá-lo no JavaScript do lado do cliente o expõe a qualquer pessoa que visualize o código-fonte da página ou intercepte o tráfego de rede. Um invasor pode extrair o AppSecret e se passar pelo aplicativo, chamando APIs do WeChat em nome do estabelecimento, acessando dados de usuários e potencialmente comprometendo toda a Conta Oficial. A arquitetura correta: a página do portal do lado do cliente recebe o código de autorização do WeChat e o encaminha para o servidor do portal por meio de uma chamada de API do lado do servidor. O servidor do portal mantém o AppSecret em uma variável de ambiente segura e realiza a troca de tokens com a API do WeChat. O AppSecret nunca sai do servidor.
Q4. Um grupo hoteleiro com 15 propriedades na Europa deseja criar um perfil de hóspede unificado que reconheça quando o mesmo hóspede chinês se hospeda em propriedades diferentes. Cada propriedade possui sua própria Conta Oficial do WeChat. Qual identificador do WeChat eles devem usar e qual configuração é necessária?
Dica: O OpenID é específico por conta. Existe um identificador diferente projetado para reconhecimento entre contas.
Ver resposta modelo
Use o UnionID. O OpenID muda por Conta Oficial, de modo que o mesmo hóspede terá 15 OpenIDs diferentes em 15 contas. O UnionID é um identificador estável que representa um usuário em todas as Contas Oficiais e aplicativos vinculados à mesma conta da Open Platform. Configuração necessária: vincule todas as 15 Contas Oficiais a uma única conta da Open Platform do WeChat. Uma vez vinculados, o UnionID é retornado na resposta do OAuth quando o usuário tiver autorizado pelo menos uma das contas vinculadas. Use o UnionID como a chave primária no CRM de hóspedes para criar perfis unificados entre propriedades e reconhecer hóspedes recorrentes, independentemente de qual propriedade eles visitem.
Continue a ler esta série
How to Set Up a Captive Portal on Starlink: A Guide for Remote & Maritime Venues
Este guia detalha como contornar o hardware nativo da Starlink e integrar um Captive Portal gerenciado na nuvem usando equipamentos de roteamento corporativos. Você aprenderá como superar a limitação de CGNAT, impor a segmentação de VLAN, gerenciar restrições de largura de banda de satélite e garantir a conformidade regulatória.
Melhores Práticas de Captive Portal: Projetando para Alta Conversão e Conformidade
Este guia técnico oferece aos gerentes de TI, arquitetos de rede e diretores de operações de locais um roteiro completo para a implantação de captive portals que equilibram a segurança de rede com uma alta conversão de usuários. O guia abrange toda a arquitetura, desde a segmentação de VLAN e autenticação RADIUS até o design de consentimento em conformidade com a GDPR e a seleção de métodos de autenticação. Extraído da experiência operacional da Purple em mais de 80.000 locais e 440 milhões de logins em 2024, cada recomendação é baseada em dados reais de implantação.
Como otimizar Captive Portals para máxima segurança de rede e conversão de usuários
Este guia fornece um blueprint técnico completo para otimizar captive portals em ambientes corporativos, cobrindo arquitetura de segmentação de rede, seleção de métodos de autenticação, design de consentimento em conformidade com o GDPR e otimização de conversão. Ele foi escrito para gerentes de TI, arquitetos de rede e CTOs em hotéis, redes de varejo, estádios e organizações do setor público que precisam equilibrar a segurança de rede com a captura de dados primários (first-party data). A Purple opera a infraestrutura de captive portal em mais de 80.000 locais, com 440 milhões de logins em 2024, e as estruturas apresentadas aqui refletem essa experiência operacional.