Deprecated API

Contents

• Deprecated Classes
• Deprecated Methods

Deprecated Classes

org.apache.shiro.crypto.hash.AbstractHash
in Shiro 1.1 in favor of using the concrete SimpleHash implementation directly.

org.apache.shiro.realm.ldap.DefaultLdapContextFactory
replaced by the JndiLdapContextFactory implementation. This implementation will be removed prior to Shiro 2.0

org.apache.shiro.authc.credential.Md2CredentialsMatcher
since 1.1 - use the HashedCredentialsMatcher directly and set its hashAlgorithmName property.

org.apache.shiro.authc.credential.Md5CredentialsMatcher
since 1.1 - use the HashedCredentialsMatcher directly and set its hashAlgorithmName property.

org.apache.shiro.authc.credential.Sha1CredentialsMatcher
since 1.1 - use the HashedCredentialsMatcher directly and set its hashAlgorithmName property.

org.apache.shiro.authc.credential.Sha256CredentialsMatcher
since 1.1 - use the HashedCredentialsMatcher directly and set its hashAlgorithmName property.

org.apache.shiro.authc.credential.Sha384CredentialsMatcher
since 1.1 - use the HashedCredentialsMatcher directly and set its hashAlgorithmName property.

org.apache.shiro.authc.credential.Sha512CredentialsMatcher
since 1.1 - use the HashedCredentialsMatcher directly and set its hashAlgorithmName property.

Deprecated Methods

org.apache.shiro.mgt.DefaultSecurityManager.bind(Subject)
in favor of save(subject).

org.apache.shiro.realm.ldap.LdapContextFactory.getLdapContext(String, String)
the LdapContextFactory.getLdapContext(Object, Object) method should be used in all cases to ensure more than String principals and credentials can be used.

org.apache.shiro.realm.ldap.JndiLdapContextFactory.getLdapContext(String, String)
the JndiLdapContextFactory.getLdapContext(Object, Object) method should be used in all cases to ensure more than String principals and credentials can be used. Shiro no longer calls this method - it will be removed before the 2.0 release.

org.apache.shiro.realm.ldap.DefaultLdapContextFactory.getLdapContext(String, String)
the DefaultLdapContextFactory.getLdapContext(Object, Object) method should be used in all cases to ensure more than String principals and credentials can be used. Shiro no longer calls this method - it will be removed before the 2.0 release.

org.apache.shiro.authc.credential.HashedCredentialsMatcher.getSalt(AuthenticationToken)
since Shiro 1.1. Hash salting is now expected to be based on if the AuthenticationInfo returned from the Realm is a SaltedAuthenticationInfo instance and its getCredentialsSalt() method returns a non-null value. This method and the 1.0 behavior still exists for backwards compatibility if the Realm does not return SaltedAuthenticationInfo instances, but it is highly recommended that Realm implementations that support hashed credentials start returning SaltedAuthenticationInfo instances as soon as possible.

This is because salts should always be obtained from the stored account information and never be interpreted based on user/Subject-entered data. User-entered data is easier to compromise for attackers, whereas account-unique (and secure randomly-generated) salts never disseminated to the end-user are almost impossible to break. This method will be removed in Shiro 2.0.

org.apache.shiro.authc.credential.HashedCredentialsMatcher.isHashSalted()
since Shiro 1.1. Hash salting is now expected to be based on if the AuthenticationInfo returned from the Realm is a SaltedAuthenticationInfo instance and its getCredentialsSalt() method returns a non-null value. This method and the 1.0 behavior still exists for backwards compatibility if the Realm does not return SaltedAuthenticationInfo instances, but it is highly recommended that Realm implementations that support hashed credentials start returning SaltedAuthenticationInfo instances as soon as possible.

This is because salts should always be obtained from the stored account information and never be interpreted based on user/Subject-entered data. User-entered data is easier to compromise for attackers, whereas account-unique (and secure randomly-generated) salts never disseminated to the end-user are almost impossible to break. This method will be removed in Shiro 2.0.

org.apache.shiro.mgt.DefaultSubjectFactory.newSubjectInstance(PrincipalCollection, boolean, String, Session, SecurityManager)
since 1.2 - override DefaultSubjectFactory.createSubject(org.apache.shiro.subject.SubjectContext) directly if you need to instantiate a custom Subject class.

org.apache.shiro.authc.credential.HashedCredentialsMatcher.setHashSalted(boolean)
since Shiro 1.1. Hash salting is now expected to be based on if the AuthenticationInfo returned from the Realm is a SaltedAuthenticationInfo instance and its getCredentialsSalt() method returns a non-null value. This method and the 1.0 behavior still exists for backwards compatibility if the Realm does not return SaltedAuthenticationInfo instances, but it is highly recommended that Realm implementations that support hashed credentials start returning SaltedAuthenticationInfo instances as soon as possible.

This is because salts should always be obtained from the stored account information and never be interpreted based on user/Subject-entered data. User-entered data is easier to compromise for attackers, whereas account-unique (and secure randomly-generated) salts never disseminated to the end-user are almost impossible to break. This method will be removed in Shiro 2.0.

org.apache.shiro.realm.ldap.DefaultLdapContextFactory.setSearchBase(String)
this attribute existed, but was never used in Shiro 1.x. It will be removed prior to Shiro 2.0.

org.apache.shiro.mgt.DefaultSecurityManager.unbind(Subject)
in Shiro 1.2 in favor of DefaultSecurityManager.delete(org.apache.shiro.subject.Subject)