Re: CredentialsMatcher vs PasswordMatcher

[edcincy <ed...@yahoo.com>]

Nothing like responding to your own post...

I figured this out.

PasswordMatcher *IS* the CredentialsMatcher.

When the shiro.ini file is set to use PasswordMatcher as the
CredentialsMatcher like so...

*[main]
passwordMatcher = org.apache.shiro.authc.credential.PasswordMatcher
passwordService = org.apache.shiro.authc.credential.DefaultPasswordService
passwordMatcher.passwordService = $passwordService

myRealm = rf.gae.DatastoreRealm
myRealm.credentialsMatcher = $passwordMatcher*


Thus when "getCredentialsMatcher()" is called by Shiro, the PasswordMatcher
is returned.

The raw string password input by the user, is hashed by the PasswordService,
the same as when originally stored.

The user's encrypted password then needs to be retrieved from your DB.

These two passwords are then compared... if they match, then
"isAuthenticated()" will return *true*
If they do not match, an Exception is thrown.


Whew!





--
View this message in context: http://shiro-user.582556.n2.nabble.com/CredentialsMatcher-vs-PasswordMatcher-tp7578063p7578064.html
Sent from the Shiro User mailing list archive at Nabble.com.

Re: CredentialsMatcher vs PasswordMatcher

[Les Hazlewood <lh...@apache.org>]

The original Nabble post was not accepted by the Apache Shiro mailing
list, which is why we didn't see it.  I think folks using Nabble
should subscribe to the list directly and then use Nabble for posting
if they prefer that interface.

As to your issue, yes, PasswordMatcher is a specific implementation of
the CredentialsMatcher interface.  While CredentialsMatcher can handle
_any_ type of credentials comparison (e.g. biometric scan, etc), the
PasswordMatcher is a specific implementation that focuses on
text-based passwords, the most common form of credentials.

The PasswordMatcher implementation in turn delegates to a
PasswordService instance as its implementation strategy (to leverage
existing functionality instead of duplicating it).  We hoped to
capture that point in the class JavaDoc: "This class is essentially a
bridge between the generic CredentialsMatcher interface and the more
specific PasswordService component."

Also, the PasswordService JavaDoc shows a sample shiro.ini configuration:

http://shiro.apache.org/static/1.2.1/apidocs/org/apache/shiro/authc/credential/PasswordService.html

But clearly this should also be reflected in the PasswordMatcher
JavaDoc to minimize for confusion.  Thanks for your post!

Best,

--
Les Hazlewood | @lhazlewood
CTO, Stormpath | http://stormpath.com | @goStormpath | 888.391.5282
Stormpath wins GigaOM Structure Launchpad Award! http://bit.ly/MvZkMk

On Sun, Dec 16, 2012 at 1:56 PM, edcincy <ed...@yahoo.com> wrote:
>
> Nothing like responding to your own post...
>
> I figured this out.
>
> PasswordMatcher *IS* the CredentialsMatcher.
>
> When the shiro.ini file is set to use PasswordMatcher as the
> CredentialsMatcher like so...
>
> *[main]
> passwordMatcher = org.apache.shiro.authc.credential.PasswordMatcher
> passwordService = org.apache.shiro.authc.credential.DefaultPasswordService
> passwordMatcher.passwordService = $passwordService
>
> myRealm = rf.gae.DatastoreRealm
> myRealm.credentialsMatcher = $passwordMatcher*
>
>
> Thus when "getCredentialsMatcher()" is called by Shiro, the PasswordMatcher
> is returned.
>
> The raw string password input by the user, is hashed by the PasswordService,
> the same as when originally stored.
>
> The user's encrypted password then needs to be retrieved from your DB.
>
> These two passwords are then compared... if they match, then
> "isAuthenticated()" will return *true*
> If they do not match, an Exception is thrown.
>
>
> Whew!
>
>
>
>
>
> --
> View this message in context: http://shiro-user.582556.n2.nabble.com/CredentialsMatcher-vs-PasswordMatcher-tp7578063p7578064.html
> Sent from the Shiro User mailing list archive at Nabble.com.