Bom, para mim, isto significa que somente o “Admin” com o método POST consegue acessar o recurso da URL (/TestApplication/*). ok ??? (eu axo q sim !!!)
No livro HF JSP/Servlet menciona, mais ou menos assim, o seguinte parágrafo:
[quote]
Se não declarar nenhum , todos os métodos serão irrestrito para acessar o recurso.
[/quote]:
A minha dúvida é: Isso está realemente certo ??? Na minha opinião, tinha que ser declarado o método restrito, os demais teriam que ser barrados pelo Container !!!
Outra dúvida, está certo o meu compreendimento por esse assunto ???
A minha dúvida é: Isso está realemente certo ??? Na minha opinião, tinha que ser declarado o método restrito, os demais teriam que ser barrados pelo Container !!!
Outra dúvida, está certo o meu compreendimento por esse assunto ???
Muito Obrigado
Ricardo[/quote]
Essa parte em destaque você confundiu, tem que ser declarado o método que será restrito (OK), mas os demais serão de LIVRE acesso, e não serão barrados pelo conteiner.
por exemplo, no seu caso, qualquer usuário (admin, member etc…) vai conseguir fazer um GET, PUT ou um DELETE aqui:
você somente pediu restrição nessa url para o POST.
[EDIT]
esclarecendo aqui, é exatamente o contrário do que você pensou, não é somente o “Admin” no método “POST”, mas sim no método “POST” apenas o “Admin”, no GET, PUT, DELETE está liberado pra todo mundo.
Pense o seguinte, tudo é livre até que se diga o contrário, ou seja, você disse apenas “Admin” e “Post”, então todos os demais estão como livre acesso nos outros métodos que não seja o “Post”, pois este você proibiu. (lembre que todo mundo é livre até que você diga o contrário).
Uma outra coisa que estou tendo dúvidas está sendo com relação ao termos utilizados. Por exemplo nesse trecho:
[quote]Essa parte em destaque você confundiu, tem que ser declarado o método que será restrito (OK), mas os demais serão de LIVRE acesso, e não serão barrados pelo conteiner.
por exemplo, no seu caso, qualquer usuário (admin, member etc…) vai conseguir fazer um GET, PUT ou um DELETE aqui[/quote]
Quando vc quer dizer “barrado”, ou “restrito”, quer dizer exigir autenticação (login e senha) do usuário ??? ou realmente bloquear a requisição não permitindo qualquer forma de solicitação. Receber um 404 / NOT FOUND ???
Uma outra coisa que estou tendo dúvidas está sendo com relação ao termos utilizados. Por exemplo nesse trecho:
[quote]Essa parte em destaque você confundiu, tem que ser declarado o método que será restrito (OK), mas os demais serão de LIVRE acesso, e não serão barrados pelo conteiner.
por exemplo, no seu caso, qualquer usuário (admin, member etc…) vai conseguir fazer um GET, PUT ou um DELETE aqui[/quote]
Quando vc quer dizer “barrado”, ou “restrito”, quer dizer exigir autenticação (login e senha) do usuário ??? ou realmente bloquear a requisição não permitindo qualquer forma de solicitação. Receber um 404 / NOT FOUND ???
Muito Obrigado
Ricardo[/quote]
Isso, no caso quando você implementa estes recursos de segurança, você guarda no banco quais “roles” o usuário possui, e quando você tentar acessar o recurso o conteiner verifica se este usuário possui permissão naquela url, caso não tenha, se não me engano ele mostra algo assim:
mas é claro que você pode personalizar essa mensagem para alguma mais sugestiva ao usuário.
Se o usuário já estiver logado, ele vai direto pra essa página de erro no caso, agora se não tiver logado, ele vai pedir login/senha e depois mostrar esse erro caso não possua permissão.
Uma outra coisa que estou tendo dúvidas está sendo com relação ao termos utilizados. Por exemplo nesse trecho:
[quote]Essa parte em destaque você confundiu, tem que ser declarado o método que será restrito (OK), mas os demais serão de LIVRE acesso, e não serão barrados pelo conteiner.
por exemplo, no seu caso, qualquer usuário (admin, member etc…) vai conseguir fazer um GET, PUT ou um DELETE aqui[/quote]
Quando vc quer dizer “barrado”, ou “restrito”, quer dizer exigir autenticação (login e senha) do usuário ??? ou realmente bloquear a requisição não permitindo qualquer forma de solicitação. Receber um 404 / NOT FOUND ???
Muito Obrigado
Ricardo[/quote]
[/quote]
A idéia é essa que está em destaque, só não é um 404 porque seria um recurso não entrado, nesse caso é um recurso com acesso negado, acho que é erro 503.
No caso quando você implementa estes recursos de segurança, você guarda no banco quais “roles” o usuário possui, e quando você tentar acessar o recurso o conteiner verifica se este usuário possui permissão naquela url, caso não tenha, se não me engano ele mostra algo assim:
mas é claro que você pode personalizar essa mensagem para alguma mais sugestiva ao usuário.
Se o usuário já estiver logado, ele vai direto pra essa página de erro no caso, agora se não tiver logado, ele vai pedir login/senha e depois mostrar esse erro caso não possua permissão.
Entende-se então que, a principio todos terão acesso e que através das declarações é possível restringir (autenticar através de login / password) tais funções (Admin, Member) e o restante de métodos (GET, PUT, DELETE) estão liberados para qualquer outras funções (Employee).
Entende-se então que, a principio todos terão acesso e que através das declarações é possível restringir (autenticar através de login / password) tais funções (Admin, Member) e o restante de métodos (GET, PUT, DELETE) estão liberados para qualquer outras funções (Employee).
Desculpe trazer esse topico de volta mas eu vi essa citacao abaixo e nao concordo, desculpe se estou errada, porem eu fiz uns testes e nao aconteceu assim.
"Entende-se então que, a principio todos terão acesso e que através das declarações é possível restringir "
O que vc disse “a principio todos terao acesso” estah errado … levando em consideracao que “a principio” signifique nao ter nenhum .
Meu entendimento eh que se nao existe nenhum , o recurso estah restrito em todos os metodos http e soh serah acessado pelo role que estah no atraves de autenticacao.
Uma vez que voce coloque pelo menos UM , entao o recurso estah restrito APENAS para aquele unico metodo DECLARADO e soh acessara o role quem estah no atraves de autenticacao e todos os demais metodos NAO DECLARADOS no estarao liberados a todos os outros roles, sem autenticacao.
[quote=Carol M de Paula]Desculpe trazer esse topico de volta mas eu vi essa citacao abaixo e nao concordo, desculpe se estou errada, porem eu fiz uns testes e nao aconteceu assim.
"Entende-se então que, a principio todos terão acesso e que através das declarações é possível restringir "
O que vc disse “a principio todos terao acesso” estah errado … levando em consideracao que “a principio” signifique nao ter nenhum .
Meu entendimento eh que se nao existe nenhum , o recurso estah restrito em todos os metodos http e soh serah acessado pelo role que estah no atraves de autenticacao.
Uma vez que voce coloque pelo menos UM , entao o recurso estah restrito APENAS para aquele unico metodo DECLARADO e soh acessara o role quem estah no atraves de autenticacao e todos os demais metodos NAO DECLARADOS no estarao liberados a todos os outros roles, sem autenticacao.
Certo?[/quote]
Creio que você não tenha entendido o que foi dito.
Quando foi dito “a principio todos terao acesso”, isso quer dizer que se você não colocar nenhum
todos terão acesso, imagine seu web.xml totalmente limpo, sem qualquer declaração de segurança, nesse caso TODOS TERÃO ACESSO ATÉ QUE SE DIGA O CONTRÁRIO, nesse caso dizer o contrário é começar a declarar a segurança inserindo um e seus elementos. Entenda assim.
Se você fizer uma aplicaçao teste e não inserir QUALQUER declaração de segurança, TODOS usuários terão acessos a TODOS os métodos sem qualquer autenticação, ou seja, “a princípio todos terão acesso”.
[quote=Javabuntu]
Creio que você não tenha entendido o que foi dito.
Quando foi dito “a principio todos terao acesso”, isso quer dizer que se você não colocar nenhum
todos terão acesso, imagine seu web.xml totalmente limpo, sem qualquer declaração de segurança, nesse caso TODOS TERÃO ACESSO ATÉ QUE SE DIGA O CONTRÁRIO, nesse caso dizer o contrário é começar a declarar a segurança inserindo um e seus elementos. [/quote]
Javabuntu, agora ficou mais clara a explicacao. Obrigada. Desculpe, porem sem dizer a quais tags do xml voce se referia estava dificil entender o que voces estavam dizendo ai nas mensagens do forum. Ajudou bastante a discussao! Bom fim de semana!