Integrating WeChat WiFi Authentication: Captive Portal Onboarding for APAC Customers
WeChat has 1.41 billion monthly active users, making it the primary digital identity for Chinese consumers globally. This guide explains how to integrate WeChat OAuth 2.0 authentication into enterprise captive portals for APAC venues, covering platform registration, scope selection, RADIUS Change of Authorisation enforcement, and dual-framework compliance with GDPR and China's PIPL. It is aimed at IT managers, network architects, and venue operations directors who need to act this quarter.
Ouça este guia
Ver transcrição do podcast
Resumo Executivo
Para estabelecimentos corporativos que operam na região APAC ou que atendem a turistas chineses globalmente, a autenticação de WiFi do WeChat não é mais opcional. Com 1,41 bilhão de usuários ativos mensais em 2025 (fonte: Tencent), o WeChat é a principal identidade digital dos consumidores chineses. Um visitante que se conecta ao seu SSID e vê apenas opções de login por e-mail ou Facebook enfrenta atrito imediato. Eles quase certamente têm o WeChat. Eles quase certamente não têm um endereço de e-mail local configurado nesse dispositivo.
Este guia detalha como integrar o WeChat OAuth 2.0 em um Captive Portal. Abordamos os dois registros de plataforma distintos que a Tencent exige, a decisão de escopo que determina quais dados primários você coleta e o mecanismo RADIUS Change of Authorisation (CoA) que traduz uma troca de OAuth bem-sucedida em acesso real à rede. Também abordamos os requisitos de conformidade sobrepostos do GDPR e da Lei de Proteção de Informações Pessoais da China (PIPL).
A plataforma Guest WiFi da Purple automatiza a camada de aplicação de rede em hardware Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet. A Purple opera em mais de 80.000 locais ativos e registrou 440 milhões de logins em 2024 (dados internos da Purple).
Análise Técnica Detalhada
O Fluxo OAuth 2.0
Um Captive Portal (um gateway de autenticação baseado na web que intercepta o tráfego HTTP de dispositivos não autenticados) redireciona os visitantes para uma página de login hospedada em um servidor de portal, local ou na nuvem. Adicionar o WeChat OAuth insere a infraestrutura de identidade da Tencent nesse fluxo.
A sequência funciona da seguinte forma. O visitante se associa ao SSID. O controlador sem fio detecta a ausência de uma sessão autenticada e redireciona todo o tráfego HTTP para a URL do Captive Portal. A página do portal é carregada e apresenta as opções de login, incluindo o WeChat. O visitante seleciona o WeChat. O servidor do portal cria um redirecionamento para o endpoint de autorização do WeChat em open.weixin.qq.com, passando quatro parâmetros: o AppID, a URI de redirecionamento, o tipo de resposta definido como code e o escopo solicitado.
WeChat authenticates the user entirely on its own infrastructure. If the guest is already signed in via the WeChat in-app browser, the snsapi_base scope allows silent authentication with no visible prompt. WeChat redirects back to the portal's registered redirect URI with a short-lived authorisation code. The portal server exchanges this code for an access token by calling api.weixin.qq.com/sns/oauth2/access_token with the AppID, AppSecret, code, and grant type. WeChat returns an access token, a refresh token, the user's OpenID, and the granted scope. If snsapi_userinfo was requested, a second API call to api.weixin.qq.com/sns/userinfo retrieves the user's nickname, profile image, gender, and city.
Platform registration: the decision that trips most deployments
Tencent operates two separate developer platforms, and selecting the wrong one is the most common cause of failed implementations.
| Access context | Required registration | Platform URL | Supported scopes |
|---|---|---|---|
| WeChat in-app browser | Service Account (Official Accounts Platform) | mp.weixin.qq.com | snsapi_base, snsapi_userinfo |
| Standard mobile browser (Chrome, Safari) | Website Application (Open Platform) | open.weixin.qq.com | snsapi_login (QR code flow) |
A Subscription Account on the Official Accounts Platform will not work. It lacks OAuth web page authorisation permissions. Only a Service Account carries those permissions.
Most enterprise deployments in Hospitality and Retail implement both registrations. A guest at a hotel might open the portal in Chrome, scan a QR code with WeChat, and authenticate via the Open Platform flow. Or they might follow a link inside WeChat itself, land in the in-app browser, and authenticate silently via the Official Accounts flow. Both paths must be handled.
Scope selection and data collection
The OAuth scope is a genuine architectural decision, not a configuration detail. It determines the friction the user experiences and the data your WiFi Analytics platform receives.
snsapi_base returns only the OpenID - a stable, unique identifier for that user within your Official Account. It requires no user consent prompt. Authentication is invisible. Use this for returning guests whose profiles you already hold, or for high-throughput environments such as stadiums and transport hubs where connection speed is the priority.
snsapi_userinfo retorna o OpenID mais o apelido, imagem de perfil, gênero, configuração de idioma e cidade. Isso aciona uma tela de consentimento explícito. Use isso para o registro de visitantes de primeira viagem para criar um perfil de dados primários (first-party data), combinado com uma camada de consentimento em conformidade com a PIPL e o GDPR na página do portal.
A regra prática: use snsapi_base para velocidade, snsapi_userinfo para dados. Você pode implementar ambos verificando se o OpenID do usuário já existe em seu banco de dados. Se existir, solicite snsapi_base. Se não existir, solicite snsapi_userinfo.
Aplicação de rede: RADIUS CoA e desvio de MAC (MAC bypass)
Um token OAuth comprova a identidade. Ele não abre a rede. Um mecanismo separado deve traduzir a autenticação bem-sucedida em uma alteração de política de rede.
O RADIUS Change of Authorisation (CoA), definido na RFC 3576, é a abordagem padrão. Depois que o servidor do portal recebe um token OAuth válido, ele envia uma solicitação de CoA para o controlador sem fio. O controlador atualiza a sessão, movendo o dispositivo da VLAN do walled garden (um segmento de rede restrito que permite apenas o tráfego do portal) para a VLAN de visitantes completa. Isso funciona com Cisco Meraki, HPE Aruba, Ruckus, Juniper Mist, Ubiquiti UniFi, Cambium, Extreme e Fortinet.
O desvio de endereço MAC (MAC address bypass) registra o endereço MAC do dispositivo como um cliente autorizado após o OAuth bem-sucedido. O controlador então permite o tráfego desse endereço sem novos desafios. É mais simples de implementar, mas traz dois riscos: os endereços MAC podem ser clonados, e o iOS 14 e o Android 10 em diante usam a randomização de endereço MAC por padrão, o que quebra o mecanismo na reconexão.
Para qualquer implantação onde a segurança seja importante, o RADIUS CoA é a escolha correta. Para saber mais sobre como proteger redes de visitantes, consulte What Is Secure WiFi: Essential Guide for Business 2026 e Enterprise WiFi Security: A Complete Guide for 2026 .
Guia de implementação
Checklist de pré-implantação
Antes de escrever uma única linha de configuração, conclua estas cinco etapas.
Primeiro, determine o contexto de acesso. Avalie o seu local e identifique se os visitantes encontrarão o portal dentro do navegador interno do WeChat, em um navegador móvel padrão ou em ambos. A resposta determina os requisitos de registro da sua plataforma.
Segundo, registre-se na plataforma correta. Para acesso pelo navegador interno do aplicativo, crie uma Conta de Serviço (Service Account) na WeChat Official Accounts Platform. Para acesso em navegador padrão, registre um Aplicativo de Website na WeChat Open Platform. Anote o AppID e o AppSecret de cada um.
Terceiro, configure suas URIs de redirecionamento. Registre cada domínio e subdomínio que seu portal utiliza, incluindo ambientes de homologação. O WeChat exige validação de correspondência exata. Uma divergência retorna o erro 40029.
Quarto, implemente a troca de tokens do lado do servidor. O AppSecret nunca deve aparecer no código do lado do cliente. Crie um endpoint do lado do servidor que aceite o código de autorização, troque-o por um token e retorne apenas os dados que seu portal necessita.
Quinto, implemente o parâmetro state para proteção contra CSRF. Gere um valor criptograficamente aleatório, armazene-o na sessão do usuário, passe-o na requisição OAuth e valide-o no retorno.
Etapas de configuração para Ruckus SmartZone
Para locais que utilizam o Ruckus SmartZone, a configuração do portal WeChat fica em Services and Profiles, depois em Hotspots and Portals e, em seguida, na aba WeChat. Você configura a URL de Autenticação (o endpoint de callback do WeChat do seu servidor de portal), o Destino DNAT (o servidor que lida com redirecionamentos de clientes não autenticados) e o Período de Carência (a janela durante a qual um usuário recentemente desconectado pode se reconectar sem se reautenticar, com padrão de 60 minutos). Você também configura a whitelist do walled garden para permitir o tráfego para os endpoints de API do WeChat durante a fase de autenticação. Consulte também o Guia Passo a Passo: Configurando Controladoras Sem Fio Ruijie para Captive Portals de WiFi para Visitantes para padrões comparáveis de configuração de controladoras.
Detecção de navegador in-app
O navegador in-app do WeChat define uma string de user agent contendo MicroMessenger. Seu portal deve detectar essa string e servir o fluxo de OAuth apropriado. Se MicroMessenger estiver presente, use o fluxo de Official Accounts. Se estiver ausente, use o fluxo de código QR da Open Platform. Falhas em detectar isso corretamente geram experiências corrompidas ou erros de autenticação.
Melhores práticas
Minimização de dados e conformidade com duplo framework
O GDPR (aplicável a visitantes europeus) e a PIPL (aplicável a cidadãos chineses) exigem uma base legal para o processamento de dados pessoais, limitação clara de finalidade e minimização de dados. O escopo snsapi_base é mais fácil de justificar sob os princípios de minimização de dados do que o snsapi_userinfo. Quando você coletar dados demográficos via snsapi_userinfo, documente sua base legal, seu período de retenção e seu contrato de processamento de dados com a Tencent.
A PILP, em vigor desde novembro de 2021, exige consentimento explícito para informações pessoais sensíveis e determina que os processadores de dados fora da China implementem padrões de proteção equivalentes. Se o servidor do seu portal estiver fora da China continental, você deve avaliar se as regras de transferência internacional de dados se aplicam ao OpenID do WeChat e aos dados de perfil que você recebe.
UnionID para implantações em múltiplas propriedades
O OpenID é único por usuário por Official Account. Se você opera várias Official Accounts em diferentes propriedades, o mesmo visitante terá OpenIDs diferentes em cada uma. O WeChat fornece um UnionID que permanece consistente em todas as contas vinculadas ao mesmo registro na Open Platform. Para redes de hotéis, grupos de varejo ou operadores aeroportuários que gerenciam múltiplos locais, implemente a resolução de identidade baseada em UnionID desde o início.
Fortalecimento de segurança
Armazene o AppSecret em uma variável de ambiente ou gerenciador de segredos, nunca no código-fonte. Rotacione-o imediatamente se suspeitar de exposição. Implemente limitação de taxa (rate limiting) em seu endpoint de troca de tokens para evitar abusos. Registre todos os erros de OAuth, particularmente 40029 (código inválido) e 40163 (código expirado), pois estes indicam configuração incorreta ou varreduras ativas.
Para uma visão mais ampla da arquitetura de segurança de rede de visitantes, consulte Por que Equipamentos de WiFi Domésticos Não Devem Estar na Sua Rede de Visitantes .
Estudos de caso
Rede de hotéis de luxo, Singapura
Um hotel de luxo de 350 quartos em Singapura que atende predominantemente a um segmento de viajantes de negócios chineses implementou a autenticação do WeChat WiFi ao lado de sua opção de login por e-mail existente. Antes da implementação, a equipe da recepção relatava uma média de 15 reclamações de hóspedes por dia sobre dificuldades de login no WiFi. Os hóspedes chineses tentavam usar endereços de e-mail que não haviam configurado em seus dispositivos de viagem.
O hotel registrou uma Conta de Serviço na Plataforma de Contas Oficiais do WeChat e uma Aplicação Web na Plataforma Aberta. Eles configuraram snsapi_userinfo para conexões de primeira viagem e snsapi_base para hóspedes recorrentes identificados pelo endereço MAC. O controlador HPE Aruba foi configurado para RADIUS CoA para gerenciar a promoção de sessão.
Em 30 dias, as reclamações de login de WiFi de hóspedes caíram para menos de duas por dia. O banco de dados de WiFi Analytics do hotel cresceu em 4.200 perfis de dados proprietários (first-party) verificados no primeiro mês, com dados demográficos em nível de cidade permitindo comunicações segmentadas pós-estadia.
Shopping internacional, Kuala Lumpur
Um shopping premium em Kuala Lumpur, com 12 milhões de usuários do WeChat apenas na Malásia, precisava de uma experiência de integração de WiFi que correspondesse às expectativas digitais de sua base de compradores. O shopping operava pontos de acesso Cisco Meraki em 180.000 metros quadrados de área de varejo.
A implantação usou a plataforma Guest WiFi da Purple como sobreposição de nuvem, com o WeChat OAuth como método de autenticação principal e SMS OTP como alternativa de segurança. A arquitetura independente de hardware da Purple lidou com a integração do RADIUS CoA com a Cisco Meraki sem exigir desenvolvimento personalizado.
O shopping registrou um aumento de 34% no início de sessões de WiFi no primeiro trimestre pós-implantação, atribuído à redução do atrito de integração para os usuários do WeChat. Os dados proprietários coletados por meio dos fluxos de consentimento snsapi_userinfo permitiram que a equipe de marketing do shopping segmentasse os compradores por cidade natal para entrega de campanhas direcionadas.
Solução de problemas e mitigação de riscos
| Erro | Causa | Resolução |
|---|---|---|
| 40029 código inválido | Incompatibilidade de URI de redirecionamento ou reutilização de código | Verifique se as URIs registradas correspondem exatamente; os códigos são de uso único |
| 40163 code expired | Troca de token atrasada além de 5 minutos | Reduzir o tempo de processamento do lado do servidor; implementar lógica de nova tentativa |
| Tela em branco após a autenticação | RADIUS CoA não configurado ou falhando | Verificar as configurações de CoA do controlador e as regras de firewall na porta UDP 3799 |
| A randomização de MAC interrompe o fluxo de visitantes recorrentes | Randomização de MAC do iOS/Android | Migrar para rastreamento de sessão baseado em OpenID; evitar identificação apenas por MAC |
| snsapi_userinfo retorna campos vazios | O usuário definiu restrições de privacidade no WeChat | Tratar campos nulos de forma amigável; não exigir dados de perfil para acesso |
ROI e impacto nos negócios
O caso de negócios para a autenticação WeChat WiFi se apoia em três resultados mensuráveis.
Aquisição de dados primários (first-party). Cada autenticação snsapi_userinfo gera um perfil de visitante verificado com dados demográficos. Para um hotel de 200 quartos operando com 70% de ocupação e 40% de hóspedes chineses, isso representa aproximadamente 20.000 novos perfis verificados por ano, cada um atrelado a uma identidade do WeChat que permite o engajamento contínuo.
Redução da carga de suporte. O atrito no login é o principal fator gerador de chamadas de suporte de WiFi de visitantes. Os estabelecimentos que adicionam a autenticação do WeChat ao lado das opções existentes relatam consistentemente uma redução nas consultas de recepção relacionadas ao WiFi, liberando o tempo da equipe para interações de maior valor.
Alcance de marketing. As Contas Oficiais do WeChat permitem que os estabelecimentos enviem notificações push aos seguidores. Um visitante que se autentica por meio de sua Conta Oficial pode ser incentivado a segui-la, criando um canal de comunicação direta que opera dentro do ecossistema do WeChat, onde os consumidores chineses passam em média 82 minutos por dia (fonte: Walk the Chat).
O plano Engage da Purple estende isso ainda mais, permitindo mensagens automatizadas pós-visita, gatilhos de fidelidade e campanhas segmentadas construídas com base nos dados primários coletados no momento da autenticação do WiFi.
Definições principais
Captive Portal
Um gateway de autenticação baseado na web que intercepta o tráfego HTTP de um dispositivo não autenticado e o redireciona para uma página de login antes de conceder acesso à rede.
O mecanismo pelo qual a autenticação de WiFi de visitantes é apresentada aos usuários. O WeChat OAuth é um dos vários métodos de autenticação que um Captive Portal pode oferecer.
OAuth 2.0
Um protocolo de autorização padrão da indústria que permite que um aplicativo de terceiros (o Captive Portal) obtenha acesso limitado a um serviço web (WeChat) em nome de um usuário, sem que o usuário compartilhe sua senha com terceiros.
A estrutura subjacente que torna o login do WeChat possível. O portal nunca vê as credenciais do WeChat do usuário; ele apenas recebe um token confirmando que o WeChat os autenticou.
RADIUS CoA
Change of Authorisation (Mudança de Autorização). Um mecanismo definido na RFC 3576 que permite a um servidor RADIUS modificar dinamicamente os atributos de autorização de sessão de um cliente de rede ativo, como alterar a atribuição de VLAN.
O mecanismo de aplicação de rede que traduz uma troca bem-sucedida do WeChat OAuth em acesso real à rede. Sem o CoA, o visitante se autentica, mas o controlador não sabe que deve liberar a rede.
OpenID
Um identificador exclusivo atribuído pelo WeChat a um usuário específico para uma Conta Oficial ou Aplicativo de Site específico. É estável entre as sessões, mas difere entre as contas.
A chave primária usada para identificar um visitante em seu banco de dados de analytics de WiFi. Use UnionID se você opera múltiplas Contas Oficiais e precisa de resolução de identidade entre contas.
snsapi_base
Um escopo do WeChat OAuth que permite autenticação silenciosa, retornando apenas o OpenID do usuário sem exibir uma solicitação de consentimento.
Use para visitantes recorrentes ou ambientes de alto rendimento onde a velocidade de conexão é a prioridade. Não retorna dados demográficos além do OpenID.
snsapi_userinfo
Um escopo do WeChat OAuth que retorna o OpenID, apelido, imagem de perfil, gênero, idioma e cidade do usuário, exigindo uma tela de consentimento explícito do usuário.
Use para o primeiro registro de visitantes para criar um perfil de dados próprio (first-party). Deve ser combinado com uma camada de consentimento em conformidade com a GDPR e a PIPL.
PIPL
Personal Information Protection Law (Lei de Proteção de Informações Pessoais). A legislação de privacidade de dados abrangente da China, em vigor desde novembro de 2021, que rege como os dados pessoais de cidadãos chineses devem ser coletados, processados e transferidos.
Aplica-se a qualquer local que colete dados de cidadãos chineses via WeChat OAuth, independentemente de onde o local esteja situado. Exige consentimento explícito, limitação de finalidade e minimização de dados.
AppSecret
Uma chave criptográfica confidencial emitida pelo WeChat que autentica seu aplicativo quando ele chama a API de troca de token do WeChat.
Deve ser armazenado apenas no lado do servidor. A exposição no código do lado do cliente permite que qualquer pessoa personifique seu aplicativo e faça chamadas de API não autorizadas para o WeChat.
VLAN
Virtual Local Area Network (Rede Local Virtual). Um segmento de rede lógico que isola o tráfego na camada de enlace de dados, permitindo que uma única rede física transporte múltiplos fluxos de tráfego isolados.
Usada em implantações de Captive Portal para separar dispositivos não autenticados (VLAN de jardim murado) de visitantes autenticados (VLAN de visitantes). O RADIUS CoA move um dispositivo entre VLANs após a autenticação bem-sucedida.
UnionID
Um identificador do WeChat que permanece consistente para um determinado usuário em todas as Contas Oficiais e Aplicativos de Site vinculados ao mesmo registro na Open Platform.
Essencial para redes de hotéis, grupos de varejo e operadores de múltiplos locais que precisam reconhecer o mesmo visitante em várias propriedades, cada uma com sua própria Conta Oficial.
Exemplos práticos
Um hotel de luxo de 200 quartos em Singapura utiliza controladores HPE Aruba e atende a um grande volume de viajantes de negócios chineses. Eles desejam coletar dados demográficos de hóspedes que estão acessando pela primeira vez e garantir que os hóspedes recorrentes se conectem automaticamente sem visualizar o portal novamente. Como eles devem configurar a integração do WeChat OAuth?
Passo 1: Registre uma Conta de Serviço na WeChat Official Accounts Platform (mp.weixin.qq.com) para gerenciar o acesso dos hóspedes ao portal dentro do navegador interno do WeChat. Registre um Aplicativo Web na WeChat Open Platform (open.weixin.qq.com) para hóspedes em navegadores móveis padrão.
Passo 2: Configure o Captive Portal para detectar a string de user agent do MicroMessenger. Forneça o fluxo OAuth do Official Accounts para usuários do navegador interno do aplicativo e o fluxo de código QR do Open Platform para usuários de navegadores padrão.
Passo 3: Para conexões de primeira viagem (sem OpenID existente no banco de dados), solicite o escopo snsapi_userinfo. Apresente uma tela de consentimento em conformidade com a PIPL antes do redirecionamento do OAuth. Armazene o OpenID, apelido, cidade e gênero retornados no banco de dados de perfis dos hóspedes.
Passo 4: Para hóspedes recorrentes (OpenID existente no banco de dados), solicite o escopo snsapi_base. Isso realiza a autenticação de forma silenciosa, sem exibição de avisos ao usuário.
Passo 5: Configure o controlador HPE Aruba para RADIUS CoA na porta UDP 3799. Após o OAuth bem-sucedido, o servidor do portal envia uma solicitação de CoA para promover o dispositivo da VLAN de walled garden para a VLAN de hóspedes.
Passo 6: Implemente o registro de endereço MAC em conjunto com o OpenID para gerenciar a detecção de hóspedes recorrentes. Observe que a randomização de MAC exige o OpenID como o identificador primário, e não o endereço MAC isolado.
A equipe de TI de uma rede de varejo relata uma alta taxa de falhas nos logins de WiFi do WeChat em três shoppings. Os usuários se autenticam no WeChat, mas são redirecionados de volta para a página do portal com um erro. Os logs do portal mostram o erro 40029. Qual é a causa provável e como resolvê-la?
O erro 40029 significa que o WeChat rejeitou o código de autorização durante a troca de tokens. As duas causas mais comuns são a incompatibilidade de URI de redirecionamento e a reutilização de código.
Passo 1: Faça login no console de desenvolvedor do WeChat tanto para a Official Accounts Platform quanto para a Open Platform. Navegue até as configurações de OAuth e liste todas as URIs de redirecionamento registradas.
Passo 2: Compare-as com as URIs de redirecionamento reais que o seu servidor de portal utiliza em produção nas três localidades. Verifique se há diferenças de subdomínio (portal.brand.com vs brand.com), diferenças de protocolo (HTTP vs HTTPS) e diferenças de caminho (/callback vs /wechat/callback).
Passo 3: Registre cada variação no console do WeChat. O WeChat realiza validação de correspondência exata, não correspondência de prefixo.
Passo 4: Se as URIs coincidirem, investigue se o seu servidor de portal está tentando reutilizar códigos de autorização. Os códigos do WeChat são de uso único e expiram após cinco minutos. Se o seu servidor tentar novamente a troca de tokens com o mesmo código, ele receberá o erro 40029 na segunda tentativa.
Passo 5: Implemente idempotência no endpoint de troca de tokens para evitar solicitações duplicadas.
Questões práticas
Q1. Você está implantando um Captive Portal para um estádio com capacidade para 60.000 pessoas que sedia eventos internacionais com uma base significativa de torcedores chineses. A prioridade é colocar todos os participantes online nos primeiros 15 minutos após a abertura dos portões para reduzir o congestionamento de celular. A coleta de dados de marketing é um objetivo secundário. Qual escopo do WeChat OAuth você deve configurar e por quê?
Dica: Considere o impacto de uma tela de consentimento exibida para 15.000 usuários simultâneos em um servidor de Captive Portal.
Ver resposta modelo
Configure o escopo snsapi_base. Isso permite a autenticação silenciosa sem solicitação de consentimento do usuário, proporcionando a experiência de integração mais rápida possível. Na escala de um estádio, uma tela de consentimento adiciona fricção que se multiplica em milhares de conexões simultâneas e pode causar picos de carga no servidor do portal. O snsapi_base retorna apenas o OpenID, o que é suficiente para registrar a sessão e identificar os torcedores que retornam. Para torcedores de primeira viagem dos quais você deseja obter dados demográficos, você pode solicitar o preenchimento do perfil por meio de uma pesquisa pós-conexão, em vez de fazer isso na etapa de autenticação.
Q2. Um arquiteto de rede da sua equipe propõe armazenar o WeChat AppSecret no JavaScript do lado do cliente do Captive Portal para reduzir as viagens de ida e volta ao servidor, fazendo a chamada de troca de token diretamente do navegador. Explique por que essa abordagem é uma falha de segurança crítica e qual é a arquitetura correta.
Dica: Considere quem pode visualizar o código do lado do cliente e o que o AppSecret permite que eles façam.
Ver resposta modelo
Armazenar o AppSecret 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. O AppSecret autentica sua aplicação na API do WeChat. Com ele, um ator mal-intencionado pode se passar por sua aplicação, chamar o endpoint de troca de token do WeChat com qualquer código de autorização válido, recuperar OpenIDs e dados de perfil de usuários e, potencialmente, esgotar os limites de taxa da sua API. A arquitetura correta é um endpoint de troca de token no lado do servidor. O navegador recebe o código de autorização do WeChat e o passa para o seu servidor. Seu servidor, usando o AppSecret armazenado em uma variável de ambiente ou gerenciador de segredos, troca o código por um token e retorna apenas os dados de que o portal precisa. O AppSecret nunca sai do seu servidor.
Q3. Seu estabelecimento opera três propriedades hoteleiras em cidades diferentes, cada uma com sua própria Conta Oficial do WeChat. Um membro do programa de fidelidade que se autenticou nas três propriedades possui três OpenIDs diferentes em seu banco de dados. Como você resolve isso em uma única identidade de hóspede?
Dica: O WeChat fornece um mecanismo para resolução de identidade entre contas que requer uma configuração específica da plataforma.
Ver resposta modelo
Implemente o mecanismo UnionID do WeChat. Vincule as três Contas Oficiais ao mesmo registro de Open Platform em open.weixin.qq.com. Uma vez vinculadas, o WeChat retorna um UnionID junto com o OpenID na resposta snsapi_userinfo. O UnionID é consistente para um determinado usuário em todas as contas vinculadas ao mesmo registro de Open Platform. Migre seu banco de dados para usar o UnionID como o identificador principal de hóspede para registros entre propriedades, retendo o OpenID por conta para chamadas de API específicas de cada conta. Para hóspedes que se autenticaram antes da implementação do UnionID, acione uma nova autenticação com snsapi_userinfo na próxima visita para capturar o UnionID.
Q4. Após implantar a autenticação do WeChat WiFi em um varejo que executa pontos de acesso Cisco Meraki, os hóspedes relatam que concluem o login do WeChat com sucesso, mas retornam à página do portal e não conseguem navegar na internet. Os logs do servidor do portal mostram a recuperação de token bem-sucedida. Qual é a causa mais provável e como diagnosticá-la?
Dica: O portal verificou a identidade. O que ainda não aconteceu?
Ver resposta modelo
A Alteração de Autorização (CoA) do RADIUS não está sendo concluída. O servidor do portal verificou a identidade do hóspede via WeChat OAuth, mas não instruiu com sucesso o controlador Cisco Meraki a mover o dispositivo da VLAN do walled garden para a VLAN de convidados. Diagnostique verificando: (1) se o controlador Meraki tem o RADIUS CoA habilitado e se o IP do servidor do portal está listado como um cliente CoA autorizado; (2) se a porta UDP 3799 está aberta entre o servidor do portal e o controlador; (3) os logs do servidor do portal em busca de erros de solicitação de CoA ou timeouts; e (4) se o segredo compartilhado configurado em ambos os lados coincide. Se o CoA não for compatível com o seu nível de licença Meraki, o bypass de endereço MAC é a alternativa, embora traga o risco de randomização de MAC observado no guia.
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.