Hi,
if you need a jaas authenticated jackrabbit session you need to do the
following in the code where you create a jrc session:
Session s = (Session) Subject.doAs(subject, new PrivilegedAction() {
public Object run() {
return repository.login();
}
});
The login() without parameters will check if there is a security context
available. You only need to get the JAAS Subject and the Jackrabbit
Repository from somewhere.
maybe this helps
Stefan Guggisberg wrote:
hi nathaniel
On 1/25/07, Nathaniel Stoddard <[EMAIL PROTECTED]> wrote:
I'm still trying to get authentication with JAAS working in
Jackrabbit. I'm
gone so far as to remove all references to the SimpleLoginModule. I'm
using
glassfish. I've updated the "login.conf" file to use Glassfish's
FileLoginModule. However, I always get this error message:
Failed to create session: No credentials.: No credentials.
After downloading the source code and debugging for a while, it looks
like
the user name and password I type in never make into the credentials
object
that is visible from the FileLoginModule. Does anybody know if this
is an
unimplemented feature still, or if there's just something I've missing
configuring? I'd love to secure Jackrabbit so everybody and their mother
isn't able to screw with my content. Any help would be wonderful. I'm a
hair away from posting to the developer's list!
i haven't worked with glassfish so i can't help you there, sorry.
I've even gone so far as to setup "web-resource-collections" in my
"web.xml"
and force the authentication myself. The authentication works in that
case
(from in the FileLoginModule), but somewhere it still gets rejected. At
that point, I've successfully authenticated, have the right role to
view the
page, but the DavServlet rejects it and still sends a 403 (or whatever
error
it is, saying I don't have rights to view the page).
the only advice i got for you unfortunately involves getting your hands
dirty.
set a breakpoint on
org.apache.jackrabbit.core.RepositoryImpl#login(Credentials, String),
step trhough the code, check the call stack and see what's going on.
you can also trace the http traffic from your webdav client to the
webdav server.
very often you find some indications what's going wrong. you can e.g.
use proxy.jar which you can download here:
http://www.day.com/o.file/proxy.jar?get=a720c53071053b38ff71dbd963809841
"java -jar proxy.jar" gives you some information how to use it.
cheers
stefan
--
kind regards
Michael
