On Tue, Nov 9, 2010 at 12:47 AM, Janne Jalkanen
<[email protected]> wrote:
> And to respond to myself - the problem turns out to be that I had one
> instance where Shiro was configured implicitly and not using the
> SHIRO_CONFIG below. Turns out that this causes a conflict if you configure
> Shiro twice with different settings within the same JVM.
> It would be good if there was some sort of a check for this - the exception
> message is not exactly helping here.
It's useful to think through the whole scenario. If we actually
prevented this, it'd mean that Shiro couldn't be reconfigured
dynamically within the same JVM. Logging a warning perhaps (I'm sure
there are at least some info messages on this even currently) but how
much configuration would be enough configuration to trigger a warning?
I'll certainly evaluate concrete suggestions to mitigate this but
until then it's business as usual: if you run unit tests within the
same JVM better make sure they don't interfere with each other.
Kalle
> Folks,
> I'm rather stymied at the following problem: Whenever I run my unit tests
> one at a time, everything works. But when I run the entire suite, the tests
> fail due to
> SecurityUtils.getSubject().logout(); // Ensure we are logged out
> SecurityUtils.getSubject().login( new
> UsernamePasswordToken("[email protected]","foobar") );
>
> The failure is
> org.apache.shiro.authc.IncorrectCredentialsException: The credentials
> provided for account [org.apache.shiro.authc.UsernamePasswordToken -
> [email protected], rememberMe=false] did not match the expected credentials.
> at
> org.apache.shiro.realm.AuthenticatingRealm.getAuthenticationInfo(AuthenticatingRealm.java:191)
> at
> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doSingleRealmAuthentication(ModularRealmAuthenticator.java:179)
> at
> org.apache.shiro.authc.pam.ModularRealmAuthenticator.doAuthenticate(ModularRealmAuthenticator.java:264)
> at
> org.apache.shiro.authc.AbstractAuthenticator.authenticate(AbstractAuthenticator.java:198)
> at
> org.apache.shiro.mgt.AuthenticatingSecurityManager.authenticate(AuthenticatingSecurityManager.java:106)
> at
> org.apache.shiro.mgt.DefaultSecurityManager.login(DefaultSecurityManager.java:269)
> at
> org.apache.shiro.subject.support.DelegatingSubject.login(DelegatingSubject.java:247)
> at
> com.thinglink.site.stripes.AccountActionBeanTest.setup(AccountActionBeanTest.java:43)
> <rest is snipped away>
> I've tried different kinds of Shiro configurations, and the one that seems
> to work best right now looks like
> /** Configuration that we use in tests. */
> private static final String SHIRO_CONFIG =
> "[main]\n"+
> "credentialsMatcher =
> org.apache.shiro.authc.credential.Sha256CredentialsMatcher\n"+
> "credentialsMatcher.storedCredentialsHexEncoded = false\n"+
> "credentialsMatcher.hashSalted = true\n"+
> "cacheManager =
> org.apache.shiro.cache.MemoryConstrainedCacheManager\n"+
> "myRealm = com.thinglink.site.shiro.CassandraRealm\n"+
> "myRealm.credentialsMatcher = $credentialsMatcher\n"+
> "myRealm.cacheManager = $cacheManager\n"+
> "securityManager = org.apache.shiro.mgt.DefaultSecurityManager\n"+
> "securityManager.realm = $myRealm\n";
> // For shiro we use our internal configuration, not the one that's found
> from classpath
> Ini ini = new Ini();
> ini.load( SHIRO_CONFIG );
> IniSecurityManagerFactory smf = new IniSecurityManagerFactory( ini
> );
> SecurityUtils.setSecurityManager( smf.getInstance() );
> I've tried using a WebIniSecurityManagerFactory, but the test framework I'm
> using does not fully implement the Servlet spec, so it's not that useful; it
> fails in interesting ways and getting cookies is a pain. So I figured I
> should try just simply the basic DefaultSecurityManager as everything runs
> in a single thread anyway.
> This is with 1.1.0 release.
> Any ideas as to what could explain why the tests aren't running if I run all
> the tests? The fun thing is that this is the *only* test currently which
> actively tries to log in.
> /Janne
>
