Yoav,

This is the security configuration:
   <!--
        security configuration
    -->
    <Security appName="Jackrabbit">
        <!--
            access manager:
            class: FQN of class implementing the AccessManager interface
        -->
        <AccessManager class="org.apache.jackrabbit.core.security.SimpleAccessManager">
            <!-- <param name="config" value="${rep.home}/access.xml"/> -->
        </AccessManager>

        <LoginModule class="org.apache.jackrabbit.core.security.SimpleLoginModule">
            <!-- anonymous user name ('anonymous' is the default value) -->
            <param name="anonymousId" value="anonymous"/>
            <!--
              default user name to be used instead of the anonymous user
              when no login credentials are provided (unset by default)
           -->
            <param name="defaultUserId" value="superuser"/>
        </LoginModule>
    </Security>

I've checked this again with the config in the artifactory svn and it looks the same.

It could indeed be that something is affecting the configuration.
Tomcat is installed from repository with apt-get (debian squeeze).
The default config of such an install has a very strict policy but I've opened it up I think.
I think this also done with JAAS?? (grant codeBase .... ) or not?

Can I find the JAAS-config for artifactory somewhere?
Is there anything in particular I need to look for in the config of Tomcat?

If I understand this exception is the result of another (hiden) exception?

Regards,
Tim


Hi Tim,
The JCR user used for JCR sessions is unrelated to the users in Artifactory.
All JCR sessions are made with a built-in JCR-level super user. That's done
internally inside Artifactory and Jackrabbit is using JAAS for the
authentication.
It looks like the JCR session you are getting was never logged in, so I am
taking a guess that some JAAS-related configuration on Tomcat affects the
Jackrabbit authentication. You may be able to isolate the problem by
comparing the configuration with one of a clean Tomcat.
There's also a chance that, while editing the repo.xml file, you mistakenly
changed the security section configuration, which is causing all session
logins to fail.

Thanks,

Yoav
------------------------------------------------------------------------------
Let Crystal Reports handle the reporting - Free Crystal Reports 2008 30-Day 
trial. Simplify your report design, integration and deployment - and focus on 
what you do best, core application coding. Discover what's new with 
Crystal Reports now.  http://p.sf.net/sfu/bobj-july
_______________________________________________
Artifactory-users mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/artifactory-users

Reply via email to