A “j_security_check” é uma pseudo-página, que aparece apenas quando vc. tenta acessar um recurso protegido. Tentar acessá-la diretamente sempre acaba em confusão.
A solução é um pouco mais enrolada.
NUNCA, mas NUNCA mesmo mande o usuário e senha em claro, ainda mais por e-mail !!! (nem para recuperar senha isto vale)
Gere uma URL com um GUID ou outro identificador “difícil”. Note que isto deve estar casado com um cookie que não seja de sessão presente no browser do usuário (assim, o usuário/senha no caso passam a ser o cookie e a URL). Note que isto só é aceitável para aplicações de baixo risco…
A URL deve ser mapeada para um servlet com acesso público. Ao cair no doGet, o servlet valida o cookie e GUID e usa-os para recuperar usuário e senha de algum lugar. Salve estas informações na sessão e, em seguida , mande um redirect para uma outro recurso, desta vez protegido via no web.xml
Altere a página de logon de forma que os campos com j_username/j_password sejam preenchidos com o usuário/senha presentes na sessão em campos hidden. Use javascript para o submit automático. Coloque um texto do tipo “efetuando logon. Caso vc. não seja redirecionado em 5 segundos, clique aqui”. Isto resolve para os bloqueios de javascript mais comuns. o “aqui” é o botão que faz o submit dos campos hidden
Com sorte, a página final em que o usuário irá aportar será aquela que vc. queria passar diretamente.
valdir.mendes
Bom, pensei que existisse uma forma de fazer o commit() do Login automaticamente pela api.
Mas essa solução eu gostei, apesar de fazer uma poguizinha javascript hehhe