O Access Server ignora o script post_auth que você editou no disco

Um mac.py editado que não muda nada é o primeiro sintoma habitual. O ficheiro no disco não é o que o Access Server executa; o serviço de autenticação carrega o script da base de dados de configuração do servidor, e é essa cópia guardada que decide um início de sessão. Enquanto o valor guardado não for substituído, cada teste prova apenas que o script antigo continua a funcionar.

Três condições decidem o trabalho: se o valor alguma vez foi colocado na base de dados de configuração, se o serviço recebeu ordem para o recarregar, e se o código que alterou é realmente executado em cada ligação. Cada uma tem um sintoma diferente, e corrigir a errada desperdiça uma janela de manutenção.

O ficheiro é uma fonte, não a cópia em execução

O Access Server mantém o script post-auth sob a chave auth.module.post_auth_script. Editar o ficheiro atualiza apenas a sua cópia de trabalho. O daemon lê o valor guardado, por isso a alteração fica invisível até apagar a entrada antiga e colocar o ficheiro novo no lugar dela. Esse valor guardado é a única cópia que o serviço de autenticação consulta.

Leia-o antes de o alterar. Se já coincide com o ficheiro que editou, o problema não está no armazenamento e deve passar à questão do âmbito. Se mostra uma versão mais antiga, a alteração nunca chegou ao serviço.

./sacli -k auth.module.post_auth_script ConfigGet

Substitua a cópia guardada e só depois a aplique

Apagar antes de escrever não é decoração. ConfigPut com --value_file substitui o valor num único passo, e ConfigDel primeiro torna impossível deixar uma entrada obsoleta ou corrompida. Guarde uma cópia do script operacional fora do diretório de scripts antes de começar.

./sacli -k auth.module.post_auth_script ConfigDel
# store the file, then apply it
./sacli -k auth.module.post_auth_script --value_file=/root/post_auth.py ConfigPut
./sacli start

sacli start aplica a configuração alterada aos serviços internos, e é isso que faz o novo script entrar em vigor. Não é o mesmo que reiniciar a máquina inteira ou o daemon, e não deve ser substituído por isso, a menos que a alteração que está a fazer o exija.

Use um caminho absoluto para o ficheiro de valor e confirme que o root o consegue ler. Um caminho que se resolve a partir da sua shell mas não a partir da conta do serviço produz um valor guardado que parece correto em ConfigGet e falha no primeiro início de sessão. Verifique o resultado guardado mais uma vez depois de sacli start, não antes.

Âmbito do módulo ou por ligação: onde pertence a consulta

O Python executa as instruções de nível de módulo uma vez, quando o script é carregado. Por isso uma consulta à base de dados escrita no topo do ficheiro lê a tabela no momento do carregamento e conserva essa resposta para cada ligação posterior. É a segunda razão pela qual uma alteração parece não fazer nada: o código é executado, mas não quando o espera.

Coloque a consulta dentro do manipulador post_auth para que seja executada em cada autenticação. Mantenha a assinatura documentada, ajuste o resultado de autenticação que o manipulador recebe e devolva o mesmo objeto em vez de um número cru.

Mantenha também o tratamento da ligação dentro do manipulador. Uma ligação aberta na importação pode ser fechada pelo servidor antes de o primeiro utilizador entrar, e o erro resultante parece credenciais rejeitadas em vez de um script avariado.

Dois caminhos de rejeição, um proprietário

Se a decisão for uma consulta local, o manipulador Python é o proprietário do resultado. Se for uma verificação HTTP externa, deixe o estado de saída do comando transportar a resposta: um invólucro que termina com um código diferente de zero rejeita o início de sessão, e o estado do último comando passa a ser o estado do script sem um exit explícito.

Mantenha o segredo fora da lista de processos. Um ficheiro legível pelo root ou um valor de ambiente passado pelo serviço é mais seguro do que um argumento que qualquer utilizador local pode ler a partir de ps. Fixe o ponto final numa variável antes da chamada, para que um erro de escrita falhe na configuração e não durante o início de sessão de alguém. Rode esse segredo como faria com qualquer outra credencial.

Escolha um único proprietário por verificação. Um script que consulta a base de dados e chama um serviço HTTP precisa de uma regra de precedência declarada para o caso de ambos discordarem, caso contrário o motivo da rejeição no registo não corresponderá ao que foi dito ao utilizador.

Aplique-o sem bloquear o administrador

Duas salvaguardas tornam a alteração reversível: uma segunda conta de administrador que não dependa do script, e uma cópia boa conhecida guardada fora do diretório de scripts. Aplique a alteração numa janela de manutenção e depois observe um início de sessão de teste e uma rejeição deliberada antes de se desligar. Se o registo mostrar um erro de sintaxe em vez de uma decisão de autenticação, o script guardado está avariado e todos os inícios de sessão falharão.

Duas condições dizem espere: não consegue ler o ficheiro de valor como root, ou não tem uma segunda via para a interface de administração. Ambas transformam uma pequena alteração num bloqueio, e nenhuma merece ser testada num servidor de produção ao fim do dia. A documentação do Access Server cobre a interface post-auth e os campos que suporta.