Configuração passo a passo da autenticação
Em qualquer etapa da configuração, você pode salvar a autenticação e voltar mais tarde para a edição. Logo após a criação, você pode editar qualquer etapa individual selecionando-a no menu.
Este é um passo necessário sempre. Ele define o nome da autenticação, seu tipo e método. Se escolher o método oAuth, uma configuração adicional será obrigatória.
O tipo e o método são os únicos elementos que não podem ser editados em uma autenticação já criada. Se algo foi selecionado incorretamente, é necessário recriar a autenticação.
Este passo estará disponibilizado para configuração somente se o tipo de autenticação escolhido for “Customizado”.
São criados os campos obrigatórios para autenticação, que serão solicitados ao usuário final no momento de criar uma conexão com o aplicativo. Todos os campos criados serão exibidos para preenchimento e os valores desses campos serão salvos dentro da conexão.
Os próprios campos podem ser usados como variáveis dinâmicas nas próximas etapas, substituindo-os nas solicitações HTTP.
Ao criar um campo, você deve preencher:
Código do campo - ID interno do campo.
Nome - o nome do campo que estará aparecendo na interface para usuários finais.
Nome alternativo - o nome do campo que estará aparecendo na interface para usuários finais, exibido nas interfaces internacionais da Albato.
Dica - um texto curto explicativo que será mostrado embaixo do campo a ser preenchido.
Dica alternativa - um texto curto explicativo que será mostrado embaixo do campo a ser preenchido, exibido nas interfaces internacionais da Albato.
Tipo - a configuração do tipo do campo. Tipos suportados:
string - input de string comum;
integer - permite apenas números;
email - o campo prevê uma validação obrigatória antes de salvar, verificando se o valor inserido é um email;
password - ** será mostrado em vez de um valor inserido;
subdomain - o sub-domínio, no qual usuário visualiza um prefixo estático e um postfixo;
boolean - campo “marcação”.
Todos os campos podem ser editados e deletados.
Esta etapa fica disponível para configuração apenas se a autenticação precisar fazer requisições HTTP adicionais para receber / atualizar um token de acesso. A disponibilização acontece para os métodos de autenticação “Com login e senha” e “Com chave API”.
Nesse processo, Widgets de requisição podem ser criados e configurados, se necessário.
Se o token precisar ser atualizado por meio do refreshToken, você precisará marcar a caixa Usar RefreshToken:
Esta caixa de seleção permite, na guia Response do primeiro widget de solicitação (que recebe o token de acesso), salvar o token de atualização Refresh token recebido na resposta a uma variável:
Além disso, ao criar um widget de requisição de atualização de token, essa variável estará disponível na guia Request e o valor da variável (que salvamos anteriormente) será passado na requisição de atualização de token.
É adicionado o primeiro widget de uma solicitação para receber um token. Essa solicitação HTTP é feita no momento da criação de uma conexão. Para tanto, é necessário especificar a URL, o método e o formato da solicitação, além de personalizar o corpo e os cabeçalhos. A chave da variável é indicada no campo à esquerda e o valor no campo à direita, onde as variáveis dinâmicas (campos de autenticação) podem ser substituídas.
Também é obrigatório configurar a guia Response, que indica de qual variável de resposta você precisa obter o valor. Depois, basta salvá-lo na variável accessToken, que será posteriormente transmitida em todas as requisições HTTP de saída do aplicativo.
Se você precisar atualizar o token, adicione o mesmo widget de solicitação na seção "Atualizar token". Nesta requisição você pode passar as mesmas variáveis dinâmicas, mas, além delas, o token de acesso Access token e token de atualização Refresh token, obtido anteriormente, também devem ser informados.
É obrigatório na guia de resposta configurar o caminho de resposta para receber um novo token de acesso, atualizá-lo e salvá-lo nos campos de autenticação.
Uma solicitação de atualização é feita no momento em que qualquer uma das entidades do aplicativo faz uma requisição HTTP de saída e o aplicativo (serviço) retorna um erro indicando que o token expirou (o widget deve ter tratamento de erros com o tipo apropriado).
Esta etapa sempre aparece, para qualquer tipo e método de autenticação.
É configurado um “modelo” do comportamento de todas as futuras requisições HTTP à API, que serão associadas a esta autenticação, ou seja, serão substituídos todos os parâmetros necessários configurados nesta etapa. Esta é uma versão “simplificada” do widget de requisição.
Em todos os casos, você pode usar campos e parâmetros de autenticação. A lista de campos depende do método e tipo selecionados, por exemplo, quando o método de autenticação é oAuth com a chave API, a variável dinâmica Chave API (accessToken) fica disponível. Esta variável contém o valor que foi salvo por meio de uma solicitação HTTP configurada no Passo 3, no momento da criação de uma conexão e troca de alguns dados, por um token de acesso.
Se for selecionado o tipo de autenticação “Com login e senha”, fica disponível a variável dinâmica Login e senha no formato base64 Login e senha em formato base64. É uma concatenação do login e senha através do símbolo : , passando a codificação no formato base64.
Campos disponíveis:
Parâmetros Get - os parâmetros necessários são registrados manualmente e os valores são substituídos. Tudo o que for indicado neste campo irá transferir os dados inseridos a cada solicitação HTTP, substituindo exatamente como os parâmetros GET.
Cabeçalhos - criação dos campos de cabeçalho, indicando a chave no campo esquerdo e substituindo o valor no campo direito.
Parâmetros - criação dos campos que serão transmitidos no corpo da requisição.
Esta é a última etapa da configuração da autenticação. Depois de salvar, a configuração da autenticação é concluída e você pode prosseguir para as configurações do resto das entidades.
Passo 1. Configurando autenticação
Este é um passo necessário sempre. Ele define o nome da autenticação, seu tipo e método. Se escolher o método oAuth, uma configuração adicional será obrigatória.
O tipo e o método são os únicos elementos que não podem ser editados em uma autenticação já criada. Se algo foi selecionado incorretamente, é necessário recriar a autenticação.
Passo 2. Campos de autenticação
Este passo estará disponibilizado para configuração somente se o tipo de autenticação escolhido for “Customizado”.
São criados os campos obrigatórios para autenticação, que serão solicitados ao usuário final no momento de criar uma conexão com o aplicativo. Todos os campos criados serão exibidos para preenchimento e os valores desses campos serão salvos dentro da conexão.
Os próprios campos podem ser usados como variáveis dinâmicas nas próximas etapas, substituindo-os nas solicitações HTTP.
Ao criar um campo, você deve preencher:
Código do campo - ID interno do campo.
Nome - o nome do campo que estará aparecendo na interface para usuários finais.
Nome alternativo - o nome do campo que estará aparecendo na interface para usuários finais, exibido nas interfaces internacionais da Albato.
Dica - um texto curto explicativo que será mostrado embaixo do campo a ser preenchido.
Dica alternativa - um texto curto explicativo que será mostrado embaixo do campo a ser preenchido, exibido nas interfaces internacionais da Albato.
Tipo - a configuração do tipo do campo. Tipos suportados:
string - input de string comum;
integer - permite apenas números;
email - o campo prevê uma validação obrigatória antes de salvar, verificando se o valor inserido é um email;
password - ** será mostrado em vez de um valor inserido;
subdomain - o sub-domínio, no qual usuário visualiza um prefixo estático e um postfixo;
boolean - campo “marcação”.
Todos os campos podem ser editados e deletados.
Passo 3. Requisições HTTP de autenticação
Esta etapa fica disponível para configuração apenas se a autenticação precisar fazer requisições HTTP adicionais para receber / atualizar um token de acesso. A disponibilização acontece para os métodos de autenticação “Com login e senha” e “Com chave API”.
Nesse processo, Widgets de requisição podem ser criados e configurados, se necessário.
Se o token precisar ser atualizado por meio do refreshToken, você precisará marcar a caixa Usar RefreshToken:
Esta caixa de seleção permite, na guia Response do primeiro widget de solicitação (que recebe o token de acesso), salvar o token de atualização Refresh token recebido na resposta a uma variável:
Além disso, ao criar um widget de requisição de atualização de token, essa variável estará disponível na guia Request e o valor da variável (que salvamos anteriormente) será passado na requisição de atualização de token.
É adicionado o primeiro widget de uma solicitação para receber um token. Essa solicitação HTTP é feita no momento da criação de uma conexão. Para tanto, é necessário especificar a URL, o método e o formato da solicitação, além de personalizar o corpo e os cabeçalhos. A chave da variável é indicada no campo à esquerda e o valor no campo à direita, onde as variáveis dinâmicas (campos de autenticação) podem ser substituídas.
Também é obrigatório configurar a guia Response, que indica de qual variável de resposta você precisa obter o valor. Depois, basta salvá-lo na variável accessToken, que será posteriormente transmitida em todas as requisições HTTP de saída do aplicativo.
Se você precisar atualizar o token, adicione o mesmo widget de solicitação na seção "Atualizar token". Nesta requisição você pode passar as mesmas variáveis dinâmicas, mas, além delas, o token de acesso Access token e token de atualização Refresh token, obtido anteriormente, também devem ser informados.
É obrigatório na guia de resposta configurar o caminho de resposta para receber um novo token de acesso, atualizá-lo e salvá-lo nos campos de autenticação.
Uma solicitação de atualização é feita no momento em que qualquer uma das entidades do aplicativo faz uma requisição HTTP de saída e o aplicativo (serviço) retorna um erro indicando que o token expirou (o widget deve ter tratamento de erros com o tipo apropriado).
Passo 4. Modelo de requisições HTTP
Esta etapa sempre aparece, para qualquer tipo e método de autenticação.
É configurado um “modelo” do comportamento de todas as futuras requisições HTTP à API, que serão associadas a esta autenticação, ou seja, serão substituídos todos os parâmetros necessários configurados nesta etapa. Esta é uma versão “simplificada” do widget de requisição.
Em todos os casos, você pode usar campos e parâmetros de autenticação. A lista de campos depende do método e tipo selecionados, por exemplo, quando o método de autenticação é oAuth com a chave API, a variável dinâmica Chave API (accessToken) fica disponível. Esta variável contém o valor que foi salvo por meio de uma solicitação HTTP configurada no Passo 3, no momento da criação de uma conexão e troca de alguns dados, por um token de acesso.
Se for selecionado o tipo de autenticação “Com login e senha”, fica disponível a variável dinâmica Login e senha no formato base64 Login e senha em formato base64. É uma concatenação do login e senha através do símbolo : , passando a codificação no formato base64.
Campos disponíveis:
Parâmetros Get - os parâmetros necessários são registrados manualmente e os valores são substituídos. Tudo o que for indicado neste campo irá transferir os dados inseridos a cada solicitação HTTP, substituindo exatamente como os parâmetros GET.
Cabeçalhos - criação dos campos de cabeçalho, indicando a chave no campo esquerdo e substituindo o valor no campo direito.
Parâmetros - criação dos campos que serão transmitidos no corpo da requisição.
Esta é a última etapa da configuração da autenticação. Depois de salvar, a configuração da autenticação é concluída e você pode prosseguir para as configurações do resto das entidades.
Atualizado em: 08/12/2022
Obrigado!