Observação
O acesso a essa página exige autorização. Você pode tentar entrar ou alterar diretórios.
O acesso a essa página exige autorização. Você pode tentar alterar os diretórios.
As APIs do servidor HTTP usam o banco de dados de roteamento para aplicar verificações de acesso durante os registros. Um registro para um UrlPrefix deve passar por uma série de verificações de acesso para garantir que o usuário que está se registrando para o namespace tenha direitos de acesso. Use a função HttpAddUrl para adicionar um novo registro.
Para adicionar um novo registro com HttpAddUrl
- Se o número da porta no UrlPrefix tiver reservas ou registros para um esquema diferente do esquema no UrlPrefix, o registro falhará. Não há suporte para HTTP e HTTPS na mesma porta.
- O registro é colocado no bucket apropriado para o registro. Os buckets são baseados no tipo de host da URL, conforme descrito na seção Solicitações de Entrada de Roteamento . As etapas a seguir são relativas a esse bucket específico.
- Se existir uma entrada de registro duplicada, retorne um código de erro.
- Selecione entradas de reserva com componentes de esquema, host e porta iguais aos do UrlPrefix. A partir deles, localize a entrada com a correspondência relativeUri mais longa. Se a entrada existir, marcar permissões com base na ACL associada a essa entrada e retornará êxito. Se a entrada não existir, retorne um código ERROR_ALREADY_EXISTS.
Os exemplos a seguir ilustram o processo para instalar um registro no banco de dados de roteamento. As reservas 1 e 2 existem no banco de dados de roteamento.
- Reserva 1:
https://+:80/vroot/subdir/para o Usuário A e o Usuário C. Essa reserva é colocada no bucket "+". - Reserva 2:
https://adatum.com:80/vroot/para o Usuário B. Essa reserva é colocada no bucket "Host Explícito". - Registro:
https://+:80/vroot/subdir/por Usuário B falha devido à reserva 1. - Registro:
https://adatum.com:80/vroot/subdir/pelo Usuário B é bem-sucedido devido à reserva 2. - Registro:
https://adatum.com:80/vroot/subdir/por usuário C falha devido à reserva mais explícita 2. A reserva curinga forte não tem significado dentro do contexto da reserva ou registro explícito. - Registro:
https://+:80/vroot/subdir/por Usuário A é bem-sucedido devido à reserva 1. - Registro:
https://adatum.com:80/vroot/anotherdir/pelo Usuário B é bem-sucedido devido à reserva 2.
O marcar de acesso para registro não inclui verificações de privilégios de delegação. Não há verificações de acesso com base em reservas (consulte HttpRemoveUrl). O único requisito para excluir um registro é que o processo de chamada deve ter criado o registro.