zeph
Member-
Posts
34 -
Joined
-
Last visited
zeph's Achievements
-
O LTV não é obrigatório. Tens alguns serviços free, mas é sempre aquele receio.
-
Atenção que deves adicionar ao hash, o prefixo mencionado na documentacao de integração (página 24).
-
Os meus ficam "amarelos" com warning, o que pelos vistos é normal acontecer. Agora, o teu erro não deve acontecer. Se já estás a obter o hash assinado, o teu problema deve estar ao "estampar" a assinatura do PDF. Tens aí exemplos da malta que já assinou com o itext. Qual é o serviço para assinar o PDF que estás a usar?
-
Podes ver aqui como proceder com Autenticação gov. (A partir da página 46) Tens a automatização na página 10 (documentação integração SAFE), ponto 4.1.1.4. O flow de criação da conta já foi falado aqui, ex:
-
E o processID é o mesmo do método anterior ( v2/signatures/signHash) ?
-
Tens de passar o processID: signatures/signHash/verify?processId={processID} Tal como diz a documentação: "4.2.7 /signatures/signHash/verify Método que retorna a(s) hash(es) assinada(s). Este método deve ser invocado após a invocação do método de pedido de assinatura autorização . O Software de Faturação deve enviar o processId utilizado na invocação do método de pedido de assinatura (/v2/signatures/signHash) .
-
Neste ponto, o que respondeste? "Apresentar os dados a assinar de acordo com a política WYSIWYS (What You See Is What You Sign), diretamente no software de faturação [cf. secção 3.2.4 da POL#16]." É obvio que a aplicação segue esta politica. Não consigo compreender o que eles pretendem com estas perguntas óbvias.
-
Por exemplo, "Não permitir a instalação da aplicação em dispositivos comprometidos". Eles querem que diga o quê? Que garanta que o servidor não está compremetido? Vou lhes dizer: "Eu garanto que o servidor está ótimo!" 😅.
-
Alguém que já tenha feito a certificação com a AMA, me consegue dizer o que eles pretendem no ponto "Relatório assinado digitalmente (com LTV) com evidências de cumprimento das guidelines de integração."? Eles pretendem um relatório detalhado acerca do flow da implementação SAFE, quer a nível visual quer a nivel técnico (mostrar campos encriptados na bd, etc) ?
-
Foi adiado até 31 de Dezembro de 2023, é isso?
-
Ainda não li nada sobre.
-
O que interessa é o dominio. Podes ter qualquer coisa desde que faça parte do dominio que registaste com eles. Eles verificam depois se o dominio que usaste no redirect do oauth esta registado com eles. Por isso, podes usar qualquer subdominio desde que pertença ao dominio que registaste.
-
Tive também alguns problemas com isso e não só aí. O que faço é: 1 - POST https://preprod.autenticacao.gov.pt/OAuthResourceServer/Api/AttributeManager Espera 15 segundos 2 - GET https://preprod.autenticacao.gov.pt/OAuthResourceServer/Api/AttributeManager Enquanto/Se a resposta do GET for vazia e não ultrapasse 15 tentativas { 3 - POST https://preprod.autenticacao.gov.pt/OAuthResourceServer/Api/AttributeManager 4 - GET https://preprod.autenticacao.gov.pt/OAuthResourceServer/Api/AttributeManager Espera 5 segundos } Se não cumprisse com o ponto 3, por vezes não tinha valor no atributo da conta,. Experimenta fazer isso. Caso obtenhas as credenciais logo a seguir, aconselho a esperares 5 segundos antes de pedires e ires pedindo de 5 em 5 segundos durante x tentativas (no meu caso pus 15) caso não tenha resultado. Eles lançam este processo de credenciais de forma assíncrona e retorna-te http status 401 enquanto não apresentar resultados. Na documentação, nada é muito claro. Tive de fazer várias tentativas em erro para chegar a um resultado coerente.
-
Sim
-
Vocês não lêem a documentação ? (Apesar de ser muito má) 😛 A "chave" que permite identificar uma conta safe é formada por: • Identificador único do cidadão • NIPC da empresa; • Informação adicional (campo opcional utilizado para o cidadão fazer distinção entre contas associadas à mesma empresa). Se estás a receber esse erro , é porque já tens uma conta safe criada, no entanto estás a pedir a criação de outra com o mesmo Identificador único (dentificador único do cidadão+NIPC+Informação adicional). Em relação a tudo o que são endpoints do SAFE (authorize/signhash/crendentials,etc), tens de passar o SAFEAuthorization que é o accessToken que está no parametro "value" que apresentaste aí em cima (no teu caso, vêm com o erro da conta, mas os acessos vêm aí). O Authorization é uma Basic authentication, logo tens de enviar o "User:Password" em base64. No caso de testes, será "clientTest:Test" em base64. O processID é uma GUID. Tens essas informações discutidas já neste tópico 😄