What's the proper way to report a bug on this? There's the ASF Shiro JIRA, but it seems that it's not possible to report a bug in JIRA without having the correct permissions.
-Robert Middleton On Thu, Oct 30, 2014 at 11:29 AM, Robert Middleton <[email protected]> wrote: > The queries should all be done through the JdbcRealm class, that has the > standard JDBC queries. > > I have figured out the problem though. It turns out that shiro is > ignoring the salt when attempting to set the password up. Since I have two > columns, one for the hashed password and one for the salt, it's correctly > retrieving them but is not setting the salt when asking for the password to > be checked. It works fine as long as the database column is in the $shiro1 > format. > > -Robert Middleton > > On Wed, Oct 29, 2014 at 6:07 PM, Konrad Zuse <[email protected]> > wrote: > >> This is my code, granted I will say I have not personally tested it, but >> I helped another buddy finish his project so I believe this should work >> completely. >> >> I haven't tested it yet only because I was siill setting up my DB and I >> am finishing up other things now. >> >> I'm not 100% sure about the line "# privateSalt needs to be >> base64-encoded in shiro.ini but not in the Java code" as I got this from >> another source, but I'm not sure why one would be and one wouldn't, so >> hopefully someone else can answer that. >> >> # Hash Service Original values of PasswordService >> hashService = org.apache.shiro.crypto.hash.DefaultHashService >> hashService.hashIterations = 500,000 >> hashService.hashAlgorithmName = SHA-256 >> hashService.generatePublicSalt = true >> >> # privateSalt needs to be base64-encoded in shiro.ini but not in the Java >> code >> #Salt is randomly generated with the Secure Generator >> >> saltGenerator = org.apache.shiro.crypto.SecureRandomNumberGenerator >> hashService.privateSalt = saltGenerator.nextBytes.toBase64 >> >> >> #PasswordMatcher >> passwordMatcher = org.apache.shiro.authc.credential.PasswordMatcher >> >> #PasswordService >> passwordService = org.apache.shiro.authc.credential.DefaultPasswordService >> passwordService.hashService = $hashService >> passwordMatcher.passwordService = $passwordService >> >> #DataSource which is our Database >> ds = >> ds.serverName = >> ds.port = >> ds.databaseName = >> ds.user = >> ds.password = >> >> jdbcRealm = org.apache.shiro.realm.jdbc.JdbcRealm >> jdbcRealm.permissionsLookupEnabled = true >> jdbcRealm.authenticationQuery = SELECT password FROM Company WHERE >> username = ? >> jdbcRealm.userRolesQuery = SELECT roles FROM Company WHERE username = ? >> jdbcRealm.permissionsQuery = SELECT permissions FROM Company WHERE >> role_name = ? >> jdbcRealm.credentialsMatcher = $passwordMatcher >> jdbcRealm.dataSource=$ds >> >> securityManager.realms = $jdbcRealm >> >> >> I'm assuming all of your queries and such are done within your SQLiteConfig >> config = new SQLiteConfig(); class? Is this your own class, or is this one >> of the predefined classes? >> >> ------------------------------ >> From: [email protected] >> To: [email protected] >> Subject: RE: Configuring Shiro Programatically >> Date: Wed, 29 Oct 2014 17:54:38 -0400 >> >> >> Weird... It looks like there is an issue with the class loader, however >> why does it say "Unable to load class" then "Unabl;e to load clazz....???" >> Something is weird there. >> >> ------------------------------ >> Date: Wed, 29 Oct 2014 17:40:39 -0400 >> Subject: Re: Configuring Shiro Programatically >> From: [email protected] >> To: [email protected] >> >> Oh, that makes a bit more sense now. I've used the PasswordService and >> PasswordManager now, but I'm still unable to authenticate. I turned up >> debugging some more, and now I get the following output: >> 17:21:55.123 [SSHThread] TRACE org.apache.shiro.util.ClassUtils - Unable >> to load clazz named >> [ff72007e587a7be71ffa92b598fef97ec0de1a1354a5e241f60d1806c9cd0351] from >> class loader [sun.misc.Launcher$AppClassLoader@13cb1eb] >> 17:21:55.123 [SSHThread] TRACE org.apache.shiro.util.ClassUtils - Unable >> to load class named >> [ff72007e587a7be71ffa92b598fef97ec0de1a1354a5e241f60d1806c9cd0351] from the >> thread context ClassLoader. Trying the current ClassLoader... >> 17:21:55.124 [SSHThread] TRACE org.apache.shiro.util.ClassUtils - Unable >> to load clazz named >> [ff72007e587a7be71ffa92b598fef97ec0de1a1354a5e241f60d1806c9cd0351] from >> class loader [sun.misc.Launcher$AppClassLoader@13cb1eb] >> 17:21:55.124 [SSHThread] TRACE org.apache.shiro.util.ClassUtils - Unable >> to load class named >> [ff72007e587a7be71ffa92b598fef97ec0de1a1354a5e241f60d1806c9cd0351] from the >> current ClassLoader. Trying the system/application ClassLoader... >> 17:21:55.124 [SSHThread] TRACE org.apache.shiro.util.ClassUtils - Unable >> to load clazz named >> [ff72007e587a7be71ffa92b598fef97ec0de1a1354a5e241f60d1806c9cd0351] from >> class loader [sun.misc.Launcher$AppClassLoader@13cb1eb] >> >> The ff72... value is the hashed password, so shiro is reading from the >> database properly. However, the log messages indicate that it's trying to >> load a class with that name?? My database should be setup properly, with a >> table 'users' and columns 'password', 'password_salt', and 'username'. >> >> -Robert Middleton >> >> On Wed, Oct 29, 2014 at 2:35 PM, Konrad Zuse <[email protected]> >> wrote: >> >> Sorry, ignore my last reply, was in the middle of typing it and was goin >> g to finish it later since I didn't have time and clicked send... sorry all >> again >( >> >> >> You should, however, be using "passwordservice" and passwordmanager >> >> I don't have much time now, so I will reply again later with some code I >> have using it. >> >> >> check out this post though from Lez, who is the creator (at least I >> believe he is one of them, if not the only one). >> >> >> http://stackoverflow.com/questions/17048153/apache-shiro-using-hashing-credentials-can-not-make-login-successfully >> >> ------------------------------ >> From: [email protected] >> To: [email protected] >> Subject: RE: Configuring Shiro Programatically >> Date: Wed, 29 Oct 2014 14:33:21 -0400 >> >> >> I don't think we used HashedCredentialsMatcher anymore, >> >> ------------------------------ >> From: [email protected] >> Date: Wed, 29 Oct 2014 15:26:12 +0100 >> Subject: Re: Configuring Shiro Programatically >> To: [email protected] >> >> You're probably missing a LifecycleUtils.init(realm); >> >> Log lines come from AuthenticatingRealm most probably because JdbcRealm >> inherits those methods from AuthenticatingRealm. Typically loggers are >> initialized with the class declaring them. >> >> On Wed, Oct 29, 2014 at 3:06 PM, Robert Middleton < >> [email protected]> wrote: >> >> >> Hi, >> >> I have set up shiro programatically using the following code: >> >> SQLiteConfig config = new SQLiteConfig(); >> config.enforceForeignKeys( true ); >> HashedCredentialsMatcher cm = new HashedCredentialsMatcher( "SHA-256" ); >> cm.setHashIterations( 500000 ); >> JdbcRealm realm = new JdbcRealm(); >> org.sqlite.SQLiteDataSource ds = new org.sqlite.SQLiteDataSource( config >> ); >> ds.setUrl( "jdbc:sqlite:light.db" ); >> realm.setDataSource( ds ); >> realm.setCredentialsMatcher( cm ); >> realm.setSaltStyle( SaltStyle.COLUMN ); >> SecurityManager ss = new DefaultSecurityManager( realm ); >> SecurityUtils.setSecurityManager( ss ); >> >> However, when I try to authenticate a user, I can't log in. This worked >> find before when I used shiro.ini with no encryption on the passwords. The >> following debug information is printed out: >> >> 18:18:28.835 [SSHThread] DEBUG org.apache.shiro.realm.AuthenticatingRealm >> - Looked up AuthenticationInfo [robert] from doGetAuthenticationInfo >> 18:18:28.836 [SSHThread] DEBUG org.apache.shiro.realm.AuthenticatingRealm >> - AuthenticationInfo caching is disabled for info [robert]. Submitted >> token: [org.apache.shiro.authc.UsernamePasswordToken - robert, >> rememberMe=false]. >> 18:18:29.275 [SSHThread] DEBUG >> org.apache.shiro.authc.credential.SimpleCredentialsMatcher - Performing >> credentials equality check for tokenCredentials of type >> [org.apache.shiro.crypto.hash.SimpleHash and accountCredentials of type >> [org.apache.shiro.crypto.hash.SimpleHash] >> 18:18:29.276 [SSHThread] DEBUG >> org.apache.shiro.authc.credential.SimpleCredentialsMatcher - Both >> credentials arguments can be easily converted to byte arrays. Performing >> array equals comparison >> 18:18:29.277 [SSHThread] ERROR >> com.synexxus.gateway.connectors.SSHConnector - >> org.apache.shiro.authc.IncorrectCredentialsException: Submitted credentials >> for token [org.apache.shiro.authc.UsernamePasswordToken - robert, >> rememberMe=false] did not match the expected credentials. >> >> Since I setup the realm for the SecurityManager to be a JdbcRealm, I >> would expect that the log lines that come from >> org.apache.shiro.realm.AuthenticatingRealm would in fact come from >> org.apache.shiro.realm.jdbc.JdbcRealm. Why isn't this the case? >> >> >> >> >> -- >> *Alessio Stalla* | Software Architect >> M: +39 340 7824743 | T: +39 010 566441 | F: +39 010 8900455 >> [email protected] | www.manydesigns.com >> >> MANYDESIGNS s.r.l. >> Via G. D'Annunzio, 2/51 | 16121 Genova (GE) | Italy >> >> >>
