Tim,
The security config looks good.
Artifactory doesn't use JAAS, but the underlying Jackrabbit does. We already
encountered situations of a conflict between the container environment and
the Jackrabbit JAAS (IIRC, it was a wrong security config file being used on
JBoss instead of the one intended to be used by Jackrabbit).
We fixed that for 2.1, but for 2.0.x the easiest solution would be to
completely disable security in Tomcat (TOMCAT_SECURITY=no) and if that
doesn't work install on a clean Tomcat downloaded from Apache.
Thanks,
Yoav
On Tue, Sep 1, 2009 at 10:36 PM, Tim Boven <[email protected]> wrote:
> 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
>
>
------------------------------------------------------------------------------
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
