Criando uma Assinatura HTTPS (URL Personalizado)
Crie uma assinatura HTTPS (URL Personalizado) no serviço Notifications.
Antes de Começar
Certifique-se de que o ponto final do URL que você planeja usar para a assinatura atenda aos seguintes requisitos:
- Autenticação
- Só há suporte para Autenticação de Acesso Básico. Para obter mais informações, consulte RFC-2617: HTTP Authentication: Basic and Digest Access Authentication. Você pode especificar um nome de usuário e uma senha no URL, como em
https://user:password@domain.comouhttps://user@domain.com. No URL, codifique (escape) os caracteres anotados em RFC-3986: Uniform Resource Identifier (URI): Generic Syntax. - Certificados
- Somente certificados de uma CA (autoridade de certificação) válidas são confiáveis. Nenhum certificado autoassinado é permitido.
- criptografia
- Como acontece com qualquer protocolo de assinatura, os dados do ponto final (incluindo nome de usuário e senha, se fornecidos no URL) são criptografados em trânsito na conexão SSL estabelecida ao usar HTTPS e em repouso no banco de dados de serviço.
- Chamadas de POST
- O ponto final fornecido deve aceitar chamadas de POST. O serviço Notifications usa chamadas POST para enviar mensagens para pontos finais HTTPS (URL personalizado).
- Acessibilidade pública
-
O ponto final da assinatura HTTPS (URL Personalizado) deve ser acessível publicamente.
O serviço Notifications não suporta pontos finais privados para assinaturas HTTPS (URL Personalizado). O serviço Notifications faz uma solicitação HTTP POST ao ponto final por meio da internet pública quando você cria uma assinatura HTTPS (URL Personalizado) em um tópico.
Para verificar se o ponto final é acessível publicamente, faça uma solicitação de POST de amostra na sua máquina local.
Exemplo:
curl -X POST <endpoint> -H "Content-Type:text/plain; charset=UTF-8" --data {"key":"value"} -vSe o ponto final for acessível publicamente, o comando retornará o seguinte código de status HTTP:
200 OK - Cabeçalho não autorizado
-
O serviço da máquina cliente deve ser capaz de dar suporte à resposta
HTTP/1.1 401 Unauthorized header. Quando o ponto final recebe uma solicitação não autenticada, ele deve retornar essa resposta com um cabeçalhoWWW-Authenticate. O valor do cabeçalho deve conter a palavra-chaveBasice outros parâmetros opcionais com suporte em RFC-2617: Autenticação HTTP: Autenticação de Acesso Básico e de Compilação.Exemplo:
WWW-Authenticate: Basic
Parâmetros de consulta não são permitidos em URLs. Não há suporte para parâmetros de cabeçalho HTTP personalizados. Ao enviar uma mensagem ao ponto final do URL, o serviço Notifications adiciona metadados padrão à solicitação HTTP no cabeçalho.
Estas etapas mostram como abrir o painel Criar Assinatura na página de detalhes do tópico ao qual você deseja adicionar a assinatura. Você também pode abrir esse painel na página da lista Assinaturas, especificando o tópico no painel: Selecione Criar Assinatura e, em seguida, selecione um Tópico de Assinatura. O Notifications cria a assinatura HTTPS (URL Personalizado) e envia um URL de confirmação para seu ponto final. O URL de confirmação é válido por três (3) dias. A assinatura está pendente até que a confirmação seja recebida.
Use o comando oci ons subscription create e os parâmetros necessários para criar uma assinatura HTTPS (URL Personalizado):
oci ons subscription create --protocol "CUSTOM_HTTPS" --subscription-endpoint <URL> [...]Para obter uma lista completa de parâmetros e valores para comandos da CLI, consulte a Referência de Linha de Comando para Notificações.
Execute a operação CreateSubscription para criar uma assinatura HTTPS (URL Personalizado).
O que vem a seguir
Para ativar a nova assinatura, navegue até o URL de confirmação que foi enviado para o ponto final HTTPS.
Embora uma nova assinatura deva estar no mesmo compartimento que seu tópico pai, você pode movê-la para outro compartimento após a criação. Consulte Movendo uma Inscrição para Outro Compartimento.