You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@shiro.apache.org by Robert Middleton <rm...@synexxus.com> on 2014/10/29 15:06:17 UTC
Configuring Shiro Programatically
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?
RE: Configuring Shiro Programatically
Posted by Konrad Zuse <th...@hotmail.com>.
Very detailed, but from what you said "steve" logs in, but Robert does not.
I believe Steve is the correct way the hashed passwords are supposed to work. The salt and hash are usually together it seems, but I'm not sure if Steve has a salt attached or not.
At least this is how the command line hasher works
http://shiro.apache.org/command-line-hasher.html
It will then ask you to enter the password and then confirm it:Password to hash:
Password to hash (confirm):
When this command executes, it will print out the securely-salted-iterated-and-hashed password. For example:$shiro1$SHA-256$500000$eWpVX2tGX7WCP2J+jMCNqw==$it/NRclMOHrfOvhAEFZ0mxIZRdbcfqIBdwdwdDXW2dM=
Take this value and place it as the password in the user definition line (followed by any optional roles) as defined in the INI Users Configuration documentation. For example:[users]
...
user1 = $shiro1$SHA-256$500000$eWpVX2tGX7WCP2J+jMCNqw==$it/NRclMOHrfOvhAEFZ0mxIZRdbcfqIBdwdwdDXW2dM=
You will also need to ensure that the implicit iniRealm uses a CredentialsMatcher that knows how to perform secure hashed password comparisons. So configure this in the [main] section as well:[main]
...
passwordMatcher = org.apache.shiro.authc.credential.PasswordMatcher
iniRealm.credentialsMatcher = $passwordMatcher
...
Granted I believe there are ways to set the salt as another DB item, or even from another server I believe I read.
I wish there was more I could do to help, I will have to try my code and see how it works or not.
My buddy seemed to have everythign working when I helped him, so i'm not too sure.
Date: Thu, 30 Oct 2014 14:32:56 -0400
Subject: Re: Configuring Shiro Programatically
From: rmiddleton@synexxus.com
To: user@shiro.apache.org
The salt is stored in the database. The salt is retrieved from the database. The salt is ignored when calculating the hash of the password. The check always fails.
Here's the sequence that happens(note that this starts at the AuthenticatingRealm level):1. Starting in getAuthenticationInfo of AuthenticatingRealm, an AuthenticationInfo is looked up. This goes to getCachedAuthenticationInfo - this is null the first time, so this goes to doGetAuthenticationInfo2. doGetAuthentication info is abstract, so it is delegated to the JdbcRealmClass3. In doGetAuthenticationInfo of JdbcRealm, the salt is retrieved from the database and set in the SimpleAuthenticationInfo object that this method returns.4. The SimpleAuthenticationInfo is passed with the token to assertCredentialsMatch5. assertCredentialsMatch asks the CredentialsMatcher if the token is equal to the AuthenticationInfo6. The CredentialsMatcher in this case is a PasswordMatcher. The relevant method is doCredentialsMatch.7. The PasswordMatcher then asks the PasswordService(a DefaultPasswordService object) if the passwords match. However, DefaultPasswordService looks at the saved information, and attempts to figure out the correct hash format. 8. The discovered format is null, because there's no data in the hashed password.9. The password is hashed, but the salt data that was retrieved from the database is not used. The hashed password is not equal to the stored password. Login fails.
At some point between steps 6 and 7 there is a bug, in that the DefaultPasswordService knows nothing about the salt that is retrieved from the database. The PasswordMatcher can pass information on the salt to the DefaultPasswordService, but it does not. This is because the HashingPasswordService does not have the capability to take in the salt on the password.
For clarity, here's the database dump. User 'steve' can log in, user 'robert' cannot.
username|password|password_saltrobert|ff72007e587a7be71ffa92b598fef97ec0de1a1354a5e241f60d1806c9cd0351|64df10ba
steve|$shiro1$SHA-256$500000$ODjsYh0x1ASOx3gdXa3iGg==$d0AnmvEpA1fVfBZrUKs4u+lkVwNr1o1eBdg+rAgqRHE=|
Steve's password is in the Shiro1Crypt format, which tells shiro what formula to use, the iteration times, the salt, and the hash. User robert's format has the hashed password in one database column, and the salt in the other database column(it is using the defaults of SHA-256 and 500,000 iterations). JdbcRealm explicitly allows this format for the salt/password.
Of course, I could be fundamentally misunderstanding how these passwords are supposed to be stored in the database. I can store passwords in the Shiro1Crypt if needed, I was just surprised that the first way of storing the passwords didn't work.
-Robert Middleton
On Thu, Oct 30, 2014 at 1:13 PM, Konrad Zuse <th...@hotmail.com> wrote:
Set the salt and stuff via java, and then retrieve with your shiro.ini info.
Date: Thu, 30 Oct 2014 13:06:13 -0400
Subject: Re: Configuring Shiro Programatically
From: rmiddleton@synexxus.com
To: user@shiro.apache.org
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 <rm...@synexxus.com> 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 <th...@hotmail.com> 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 PasswordServicehashService = org.apache.shiro.crypto.hash.DefaultHashServicehashService.hashIterations = 500,000hashService.hashAlgorithmName = SHA-256hashService.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.SecureRandomNumberGeneratorhashService.privateSalt = saltGenerator.nextBytes.toBase64
#PasswordMatcherpasswordMatcher = org.apache.shiro.authc.credential.PasswordMatcher
#PasswordServicepasswordService = org.apache.shiro.authc.credential.DefaultPasswordServicepasswordService.hashService = $hashServicepasswordMatcher.passwordService = $passwordService
#DataSource which is our Databaseds = 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: thekonradzuse@hotmail.com
To: user@shiro.apache.org
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: rmiddleton@synexxus.com
To: user@shiro.apache.org
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 <th...@hotmail.com> 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: thekonradzuse@hotmail.com
To: user@shiro.apache.org
Subject: RE: Configuring Shiro Programatically
Date: Wed, 29 Oct 2014 14:33:21 -0400
I don't think we used HashedCredentialsMatcher anymore,
From: alessio.stalla@manydesigns.com
Date: Wed, 29 Oct 2014 15:26:12 +0100
Subject: Re: Configuring Shiro Programatically
To: user@shiro.apache.org
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 <rm...@synexxus.com> 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
alessio.stalla@manydesigns.com | www.manydesigns.com
MANYDESIGNS s.r.l.
Via G. D'Annunzio, 2/51 | 16121 Genova (GE) | Italy
Re: Configuring Shiro Programatically
Posted by Robert Middleton <rm...@synexxus.com>.
The salt is stored in the database. The salt is retrieved from the
database. The salt is ignored when calculating the hash of the
password. The check always fails.
Here's the sequence that happens(note that this starts at the
AuthenticatingRealm level):
1. Starting in getAuthenticationInfo of AuthenticatingRealm, an
AuthenticationInfo is looked up. This goes to getCachedAuthenticationInfo
- this is null the first time, so this goes to doGetAuthenticationInfo
2. doGetAuthentication info is abstract, so it is delegated to the
JdbcRealmClass
3. In doGetAuthenticationInfo of JdbcRealm, the salt is retrieved from the
database and set in the SimpleAuthenticationInfo object that this method
returns.
4. The SimpleAuthenticationInfo is passed with the token to
assertCredentialsMatch
5. assertCredentialsMatch asks the CredentialsMatcher if the token is equal
to the AuthenticationInfo
6. The CredentialsMatcher in this case is a PasswordMatcher. The relevant
method is doCredentialsMatch.
7. The PasswordMatcher then asks the PasswordService(a
DefaultPasswordService object) if the passwords match. However,
DefaultPasswordService looks at the saved information, and attempts to
figure out the correct hash format.
8. The discovered format is null, because there's no data in the hashed
password.
9. The password is hashed, but the salt data that was retrieved from the
database is not used. The hashed password is not equal to the stored
password. Login fails.
At some point between steps 6 and 7 there is a bug, in that the
DefaultPasswordService knows nothing about the salt that is retrieved from
the database. The PasswordMatcher can pass information on the salt to the
DefaultPasswordService, but it does not. This is because the
HashingPasswordService does not have the capability to take in the salt on
the password.
For clarity, here's the database dump. User 'steve' can log in, user
'robert' cannot.
username|password|password_salt
robert|ff72007e587a7be71ffa92b598fef97ec0de1a1354a5e241f60d1806c9cd0351|64df10ba
steve|$shiro1$SHA-256$500000$ODjsYh0x1ASOx3gdXa3iGg==$d0AnmvEpA1fVfBZrUKs4u+lkVwNr1o1eBdg+rAgqRHE=|
Steve's password is in the Shiro1Crypt format, which tells shiro what
formula to use, the iteration times, the salt, and the hash. User robert's
format has the hashed password in one database column, and the salt in the
other database column(it is using the defaults of SHA-256 and 500,000
iterations). JdbcRealm explicitly allows this format for the salt/password.
Of course, I could be fundamentally misunderstanding how these passwords
are supposed to be stored in the database. I can store passwords in the
Shiro1Crypt if needed, I was just surprised that the first way of storing
the passwords didn't work.
-Robert Middleton
On Thu, Oct 30, 2014 at 1:13 PM, Konrad Zuse <th...@hotmail.com>
wrote:
> Set the salt and stuff via java, and then retrieve with your shiro.ini
> info.
>
> ------------------------------
> Date: Thu, 30 Oct 2014 13:06:13 -0400
>
> Subject: Re: Configuring Shiro Programatically
> From: rmiddleton@synexxus.com
> To: user@shiro.apache.org
>
> 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 <
> rmiddleton@synexxus.com> 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 <th...@hotmail.com>
> 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: thekonradzuse@hotmail.com
> To: user@shiro.apache.org
> 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: rmiddleton@synexxus.com
> To: user@shiro.apache.org
>
> 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 <th...@hotmail.com>
> 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: thekonradzuse@hotmail.com
> To: user@shiro.apache.org
> Subject: RE: Configuring Shiro Programatically
> Date: Wed, 29 Oct 2014 14:33:21 -0400
>
>
> I don't think we used HashedCredentialsMatcher anymore,
>
> ------------------------------
> From: alessio.stalla@manydesigns.com
> Date: Wed, 29 Oct 2014 15:26:12 +0100
> Subject: Re: Configuring Shiro Programatically
> To: user@shiro.apache.org
>
> 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 <rmiddleton@synexxus.com
> > 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
> alessio.stalla@manydesigns.com | www.manydesigns.com
>
> MANYDESIGNS s.r.l.
> Via G. D'Annunzio, 2/51 | 16121 Genova (GE) | Italy
>
>
>
RE: Configuring Shiro Programatically
Posted by Konrad Zuse <th...@hotmail.com>.
Set the salt and stuff via java, and then retrieve with your shiro.ini info.
Date: Thu, 30 Oct 2014 13:06:13 -0400
Subject: Re: Configuring Shiro Programatically
From: rmiddleton@synexxus.com
To: user@shiro.apache.org
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 <rm...@synexxus.com> 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 <th...@hotmail.com> 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 PasswordServicehashService = org.apache.shiro.crypto.hash.DefaultHashServicehashService.hashIterations = 500,000hashService.hashAlgorithmName = SHA-256hashService.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.SecureRandomNumberGeneratorhashService.privateSalt = saltGenerator.nextBytes.toBase64
#PasswordMatcherpasswordMatcher = org.apache.shiro.authc.credential.PasswordMatcher
#PasswordServicepasswordService = org.apache.shiro.authc.credential.DefaultPasswordServicepasswordService.hashService = $hashServicepasswordMatcher.passwordService = $passwordService
#DataSource which is our Databaseds = 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: thekonradzuse@hotmail.com
To: user@shiro.apache.org
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: rmiddleton@synexxus.com
To: user@shiro.apache.org
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 <th...@hotmail.com> 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: thekonradzuse@hotmail.com
To: user@shiro.apache.org
Subject: RE: Configuring Shiro Programatically
Date: Wed, 29 Oct 2014 14:33:21 -0400
I don't think we used HashedCredentialsMatcher anymore,
From: alessio.stalla@manydesigns.com
Date: Wed, 29 Oct 2014 15:26:12 +0100
Subject: Re: Configuring Shiro Programatically
To: user@shiro.apache.org
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 <rm...@synexxus.com> 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
alessio.stalla@manydesigns.com | www.manydesigns.com
MANYDESIGNS s.r.l.
Via G. D'Annunzio, 2/51 | 16121 Genova (GE) | Italy
Re: Configuring Shiro Programatically
Posted by Robert Middleton <rm...@synexxus.com>.
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 <rm...@synexxus.com>
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 <th...@hotmail.com>
> 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: thekonradzuse@hotmail.com
>> To: user@shiro.apache.org
>> 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: rmiddleton@synexxus.com
>> To: user@shiro.apache.org
>>
>> 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 <th...@hotmail.com>
>> 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: thekonradzuse@hotmail.com
>> To: user@shiro.apache.org
>> Subject: RE: Configuring Shiro Programatically
>> Date: Wed, 29 Oct 2014 14:33:21 -0400
>>
>>
>> I don't think we used HashedCredentialsMatcher anymore,
>>
>> ------------------------------
>> From: alessio.stalla@manydesigns.com
>> Date: Wed, 29 Oct 2014 15:26:12 +0100
>> Subject: Re: Configuring Shiro Programatically
>> To: user@shiro.apache.org
>>
>> 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 <
>> rmiddleton@synexxus.com> 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
>> alessio.stalla@manydesigns.com | www.manydesigns.com
>>
>> MANYDESIGNS s.r.l.
>> Via G. D'Annunzio, 2/51 | 16121 Genova (GE) | Italy
>>
>>
>>
Re: Configuring Shiro Programatically
Posted by Robert Middleton <rm...@synexxus.com>.
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 <th...@hotmail.com>
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: thekonradzuse@hotmail.com
> To: user@shiro.apache.org
> 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: rmiddleton@synexxus.com
> To: user@shiro.apache.org
>
> 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 <th...@hotmail.com>
> 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: thekonradzuse@hotmail.com
> To: user@shiro.apache.org
> Subject: RE: Configuring Shiro Programatically
> Date: Wed, 29 Oct 2014 14:33:21 -0400
>
>
> I don't think we used HashedCredentialsMatcher anymore,
>
> ------------------------------
> From: alessio.stalla@manydesigns.com
> Date: Wed, 29 Oct 2014 15:26:12 +0100
> Subject: Re: Configuring Shiro Programatically
> To: user@shiro.apache.org
>
> 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 <rmiddleton@synexxus.com
> > 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
> alessio.stalla@manydesigns.com | www.manydesigns.com
>
> MANYDESIGNS s.r.l.
> Via G. D'Annunzio, 2/51 | 16121 Genova (GE) | Italy
>
>
>
RE: Configuring Shiro Programatically
Posted by Konrad Zuse <th...@hotmail.com>.
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 PasswordServicehashService = org.apache.shiro.crypto.hash.DefaultHashServicehashService.hashIterations = 500,000hashService.hashAlgorithmName = SHA-256hashService.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.SecureRandomNumberGeneratorhashService.privateSalt = saltGenerator.nextBytes.toBase64
#PasswordMatcherpasswordMatcher = org.apache.shiro.authc.credential.PasswordMatcher
#PasswordServicepasswordService = org.apache.shiro.authc.credential.DefaultPasswordServicepasswordService.hashService = $hashServicepasswordMatcher.passwordService = $passwordService
#DataSource which is our Databaseds = 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: thekonradzuse@hotmail.com
To: user@shiro.apache.org
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: rmiddleton@synexxus.com
To: user@shiro.apache.org
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 <th...@hotmail.com> 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: thekonradzuse@hotmail.com
To: user@shiro.apache.org
Subject: RE: Configuring Shiro Programatically
Date: Wed, 29 Oct 2014 14:33:21 -0400
I don't think we used HashedCredentialsMatcher anymore,
From: alessio.stalla@manydesigns.com
Date: Wed, 29 Oct 2014 15:26:12 +0100
Subject: Re: Configuring Shiro Programatically
To: user@shiro.apache.org
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 <rm...@synexxus.com> 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
alessio.stalla@manydesigns.com | www.manydesigns.com
MANYDESIGNS s.r.l.
Via G. D'Annunzio, 2/51 | 16121 Genova (GE) | Italy
RE: Configuring Shiro Programatically
Posted by Konrad Zuse <th...@hotmail.com>.
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: rmiddleton@synexxus.com
To: user@shiro.apache.org
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 <th...@hotmail.com> 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: thekonradzuse@hotmail.com
To: user@shiro.apache.org
Subject: RE: Configuring Shiro Programatically
Date: Wed, 29 Oct 2014 14:33:21 -0400
I don't think we used HashedCredentialsMatcher anymore,
From: alessio.stalla@manydesigns.com
Date: Wed, 29 Oct 2014 15:26:12 +0100
Subject: Re: Configuring Shiro Programatically
To: user@shiro.apache.org
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 <rm...@synexxus.com> 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
alessio.stalla@manydesigns.com | www.manydesigns.com
MANYDESIGNS s.r.l.
Via G. D'Annunzio, 2/51 | 16121 Genova (GE) | Italy
Re: Configuring Shiro Programatically
Posted by Robert Middleton <rm...@synexxus.com>.
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 <th...@hotmail.com>
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: thekonradzuse@hotmail.com
> To: user@shiro.apache.org
> Subject: RE: Configuring Shiro Programatically
> Date: Wed, 29 Oct 2014 14:33:21 -0400
>
>
> I don't think we used HashedCredentialsMatcher anymore,
>
> ------------------------------
> From: alessio.stalla@manydesigns.com
> Date: Wed, 29 Oct 2014 15:26:12 +0100
> Subject: Re: Configuring Shiro Programatically
> To: user@shiro.apache.org
>
> 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 <rmiddleton@synexxus.com
> > 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
> alessio.stalla@manydesigns.com | www.manydesigns.com
>
> MANYDESIGNS s.r.l.
> Via G. D'Annunzio, 2/51 | 16121 Genova (GE) | Italy
>
RE: Configuring Shiro Programatically
Posted by Konrad Zuse <th...@hotmail.com>.
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: thekonradzuse@hotmail.com
To: user@shiro.apache.org
Subject: RE: Configuring Shiro Programatically
Date: Wed, 29 Oct 2014 14:33:21 -0400
I don't think we used HashedCredentialsMatcher anymore,
From: alessio.stalla@manydesigns.com
Date: Wed, 29 Oct 2014 15:26:12 +0100
Subject: Re: Configuring Shiro Programatically
To: user@shiro.apache.org
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 <rm...@synexxus.com> 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
alessio.stalla@manydesigns.com | www.manydesigns.com
MANYDESIGNS s.r.l.
Via G. D'Annunzio, 2/51 | 16121 Genova (GE) | Italy
RE: Configuring Shiro Programatically
Posted by Konrad Zuse <th...@hotmail.com>.
I don't think we used HashedCredentialsMatcher anymore,
From: alessio.stalla@manydesigns.com
Date: Wed, 29 Oct 2014 15:26:12 +0100
Subject: Re: Configuring Shiro Programatically
To: user@shiro.apache.org
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 <rm...@synexxus.com> 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
alessio.stalla@manydesigns.com | www.manydesigns.com
MANYDESIGNS s.r.l.
Via G. D'Annunzio, 2/51 | 16121 Genova (GE) | Italy
Re: Configuring Shiro Programatically
Posted by Alessio Stalla <al...@manydesigns.com>.
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 <rm...@synexxus.com>
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
alessio.stalla@manydesigns.com | www.manydesigns.com
MANYDESIGNS s.r.l.
Via G. D'Annunzio, 2/51 | 16121 Genova (GE) | Italy