[roque.possamai]

# 1 ano, 11 meses atrás

Olá Kevyn.

O que exatamente ele retorna pra você? Informar a mensagem ajuda a gente a tentar identificar o real problema.

No tutorial sobre o consumo de APIs (que o Diego informou antes) é feita uma chamada para a autenticação, talvez seja interessante dar uma olhada nele.

Além disso, é importante lembrar que o tenant precisa ser informado junto com o usuário (ex: usuario@tenant.com.br).

Caso o tenant no qual você está tentando autenticar estiver configurado com autenticação federada (ADFS/SAML), o login direto na plataforma não irá funcionar (pois precisa passar pelo servidor de autenticação do cliente). Neste caso, a solução é criar uma chave de aplicação no gerenciamento de aplicações da plataforma.
Gerenciamento de aplicações

Até mais.

[roque.possamai]

# 1 ano, 11 meses atrás

Olá, tudo bem?

A princípio a URL está montada corretamente, pois é possível criar filtros múltiplos, cfme documentação:
https://api.xplatform.com.br/api-portal/pt-br/tutoriais/entidades/uso-das-apis-de-entidade-com-filtros-odata

Qual é o retorno exibido no seu caso?

[roque.possamai]

# 1 ano, 11 meses atrás

Olá Dev, tudo bem?

Esta informação precisa ser obtida diretamente com o cliente.
Ela está disponível acessando a plataforma, através no menu:
Tecnologia > Administração > Gestão dos Tenants > Configurar

Na seção “Dados do Tenant” estão listados o Tenant (que é o nome do tenant) e o Domínio.

[roque.possamai]

# 1 ano, 11 meses atrás

Bom dia Luan, tudo bem?

Fizemos um ajuste na forma de efetuar o repasse do client_id há uns dias, justamente para tratar este caso.

Agora é possível informar o client_id também via query param.
Ex: https://api.senior.com.br/platform/user/getUser?client_id=xhxhxhxhxhxhx

Sugerimos repassar sempre o client_id através do header. Nos casos em que isso não é possível, pode-se utilizar o formato do query param.

[roque.possamai]

# 1 ano, 11 meses atrás

Olá Diego, tudo bem?

A liberação completa dos recursos somente será possível para os clientes que possuem o seu próprio ambiente AWS, visto que estas permissões (e custos) ficam a cargo dele.

Para aqueles que utilizam o ambiente de customização fornecido pela Senior esta abertura não é possível. Primeiramente por questões de segurança e até mesmo propriedade intelectual, visto que todas as customizações são armazenadas em um ambiente compartilhado. Por isso, o usuário de customização que acessa o ambiente tem poucas permissões, apenas as neessárias para editar e atualizar as lambdas dos clientes bem como acessar a IDE do Cloud9.

Aproveitando o ensejo, caso você tenha visto um aviso no Cloud9 sobre o “AWS Toolkit” e uma data de depreciação, não precisa se preocupar. Desde q ela apareceu estamos em contato direto com a AWS (inclusive com o time de desenvolvimento do Cloud9) e, por enquanto, este recurso não será desabilitado (apesar da mensagem). Como eles entenderam qual é a nossa necessidade, irão pensar e implementar uma solução adicional para podermos incorporá-la à nossa solução de customização com a consequente atualização das documentações e avisos aos utilizadores.

[roque.possamai]

# 2 anos atrás

Lucas, o envio de e-mail para ecossistema@senior.com.br está normalizado.

Até mais.

[roque.possamai]

# 2 anos atrás

Olá Lucas, tudo bem?

A Senior tem o conhecimento de que, atualmente, a diferenciação das APIs públicas/privadas não está adequada e acaba gerando muitas dúvidas dos desenvolvedores externos.
Justamente por isso estamos pensando em uma forma de facilitar essa identificação e consumo. Uma delas é termos todas as APIs abaixo de um único endpoint, que será o api.senior.com.br. Esperamos em breve ter uma solução adequada e, quando a tivermos, iremos comunicar novamente sobre estas mudanças.

Quanto aos questionamentos:

– Uso das APIs por aplicações externas (projetos desenvolvidos por nós): Atualmente usamos as APIs identificadas na documentação como privadas, por exemplo a https://platform.senior.com.br/t/senior.com.br/bridge/1.0/rest/platform/user/queries/getUser. Esse tipo de API é destinada apenas ao uso interno (ecossistema Senior X)?
Resposta: Recomendamos a utilização da “versão pública” da API sempre que esta estiver disponível. Neste caso, o ideal seria utilizar a versão cujo swagger está exposto neste endereço: https://api.xplatform.com.br/api-portal/pt-br/content/apis-senior. Note que o endpoint da versão pública acaba simplificando bastante:
http://api.senior.com.br/platform/user/getUser

Para nós desenvolvedores, o uso dessa API é incorreto?
Resposta: Não é incorreto, até mesmo porque não temos todas as APIs expostas abaixo da URL api.senior.com.br – pelo menos por enquanto. Este é um dos intuitos do trabalho que comentei no início, de unificar o local das APIs públicas e privadas. Quando isto ocorrer, há uma possibilidade (que ainda é pequena) da Senior rever a abertura da chamada de APIs externas diretamente para o endpoint da plataforma (platform.senior.com.br). Assim sendo, o ideal é que sempre que for possível, o desenvolvedor externo deveria optar pela versão pública da API.

– Uso do clientId nas requisições (APIs públicas): Já foi virada a chave?
Resposta: Ainda não. Isto deverá ocorrer de fato a partir de amanhã (06/05/22). Estamos dando um tempo extra pro pessoal conseguir se ajustar.

– Sobre o e-mail disponibilizado para dúvidas (ecossistema@senior.com.br), este tem rejeitado informando que não estamos cadastrados na lista de remetentes autorizados.
Resposta: Vamos verificar com o nosso time de infra. Assim que tiver um retorno, comento aqui.

Até mais.

[roque.possamai]

# 2 anos atrás

Olá Thiago.

Não temos uma parametrização específica por cliente para definir o tempo de expiração do token da plataforma. Hoje essa definição é global.
No entanto, colocar um tempo muito curto pode trazer problemas pros demais usuários da plataforma tendo que reautenticar com frequencia.

A solução recomendada pela Senior para estes casos de “quiosque de auto-atendimento” é colocar um atalho que abre automaticamente a plataforma em uma guia anônima do browser. Também é importante orientar os usuários a sempre fecharem o browser após terminar sua utilização.

Assim evitamos, inclusive, que o usuário marque o “Lembrar de mim” equivocadamente.

[roque.possamai]

# 2 anos atrás

Olá Isabela, tudo bem?

Por questões de segurança, o getUser somente está autorizado a retornar os dados do usuário proprietário do token.
Caso você precise consultar dados de outros usuários, você vai precisar ter o recurso res://senior.com.br/security/usermanager/usuario habilitado para o usuário autenticado.

Mais detalhes sobre os recursos aqui: https://documentacao.senior.com.br/seniorxplatform/#administracao/recursos.htm

Caso não seja isso, peço que nos mostre a URL completa do endpoint, os cabeçalhos utilizados e o payload, sem esquecer de omitir informações como o token e tenant.

[roque.possamai]

# 2 anos, 1 mês atrás

Boa tarde Sarah, tudo certo?

Sobre a autenticação e utilização do token, sugerimos você consultar os tutoriais e exemplos de como consumir as APIs da plataforma senior X.
Você pode acessá-los por aqui: https://api.xplatform.com.br/api-portal/pt-br/tutoriais/consumindo-uma-api.

Temos o “Consumindo uma API”, “Integrando com o login da plataforma”, entre outros que poderão lhe auxiliar.

Até mais.

[roque.possamai]

# 2 anos, 2 meses atrás

Olá, tudo bem?

É a primeira vez que vemos este problema… precisamos investigar mais pra identificar, mas pra isso preciso das seguintes informações:

– É no ambiente de produção?
– Qual é o tenant?
– É uma nova função ou está se alterando uma já existente?
– O acesso ao cloud9 é pelo usuário admin ou outro developer?

Até mais.

[roque.possamai]

# 2 anos, 2 meses atrás

Olá Bruno.

Caso você esteja fazendo a chamada da API via javascript, é quase certeza que é o browser quem faz esse bloqueio, pois vc estará saindo de HTTPS para HTTP (o que é considerado uma falha de segurança).

O ideal é vc deixar o serviço rodando sob https pra conseguir fazer o teu teste.
Caso teu serviço seja em node, dá pra seguir algumas dicas que temos neste tutorial: https://api.xplatform.com.br/api-portal/pt-br/tutoriais/testando-frontend-local-com-token-de-acesso

Caso ainda tenha dificuldades, detalhe mais a tua solução, indicando como é este serviço, qual é o erro que está ocorrendo, etc…

Até mais.

[roque.possamai]

# 2 anos, 5 meses atrás

Olá Guilherme.

Infelimente, na arquitetura atual do serviço de customizações, onde utilizamos serviços da AWS cloud, não há um endereço de IP de saída (da Lambda) fixo.

Este assunto está no nosso radar mas para atender a esta necessidade precisaremos rever a arquitetura do serviço de customizações. Como se trata de uma alteração mais profunda que pode gerar impactos em todos os ambientes de customização, é necessário avaliar com cautela como proceder.

Por enquanto a resposta é que não temos um IP fixo.

Assim que tivermos essa feature implementada iremos comunicar aqui no blog do dev.senior e será atualizada a documentação do serviço.
Por enquanto não há uma previsão para esta funcionalidade.

[roque.possamai]

# 2 anos, 7 meses atrás

Esta é outra limitação que ainda temos no Cloud9. Para ter acesso, vc precisa liberar todas as lambdas (resource: *)… não é possível utilizar “filtros”.
Inclusive, na imagem da resposta anterior, aparece o mesmo “erro”.

Dada a natureza compartilhada de nosso ambiente, não podemos expor as customizações dos outros tenants. Então isto acaba sendo proposital.

Atualmente, nenhum ambiente Cloud9 da nossa plataforma consegue listar suas funções devido a esta “limitação”. Também por este motivo, você precisa executar aquele script bash que a criação da customização disponibiliza (copiando para o clipboard), pois é a única forma de vc baixar o código-fonte inicial que o ambiente de customização cria para você.

Att,
Roque Possamai.

[roque.possamai]

# 2 anos, 7 meses atrás

Olá Guilherme.

Isto tem acontecido com os novos ambientes devido a uma mudança no layout padrão do Cloud9.
Infelizmente não temos como automatizar esta configuração, dado que o Cloud9 até o momento, não nos disponibiliza uma forma de efetuar este ajuste dinamicamente.

Desta forma, será necessário que você faça a configuração manualmente, acessando o Cloud9, abrindo a guia “Preferências” (engrenagem no canto superior direito) e na seção AWS Settings, desabilite o AWS toolkit.

Com isso, o layout do ambiente voltará ao formato antigo.

Até mais.
Roque Possamai