Hi Kalle,
Interesting. You can see the need for the behaviour but not the need to
expose/implement it cleanly via the API.
For mine, I don't see why
'HashedCredentialsMatcher.hashProvidedCredentials' and 'getCredentials'
are protected, this makes it impossible to expose the hashing
functionality without subclassing, which means it is less trivial to
change hash provider - the parent class of your custom HCM needs to change.
So I'll implement it like so:
1. Subclass chosen implementation of HashedCredentialsMatcher and add
'getHashedCredentials' to expose 'getCredentials'
public class AppCredentialsMatcher extends Md5CredentialsMatcher // for
example
{
public Object getHashedCredentials(AuthenticationToken token)
{
return getCredentials(token);
}
}
2. add 'getHashedCredentials' to my Realm:
public String getHashedCredentials(String username, String password)
{
UsernamePasswordToken token = new
UsernamePasswordToken(username, password);
return String.valueOf(((AppCredentialsMatcher)
getCredentialsMatcher()).getHashedCredentials(token));
}
Maybe something like this could be built into the API?
Regards, paul.
On 12/11/2010 3:30 AM, Kalle Korhonen wrote:
Hmm.. if you use username as the salt, you already have stored the
salt. For my own custom and application-specifc CredentialsMatcher
implementations, I'm not too purist about these things: sometimes I've
done it by just adding a static encode operation as part of the
CredentialsMatcher, e.g.:
public static String encode(String password, int saltWidth, int
hashIterations) {...}
Kalle
On Thu, Nov 11, 2010 at 2:06 AM, Paul Stanton<p...@mapshed.com.au> wrote:
Kalle,
I think you misunderstood my question. I don't have a problem with using the
username as the salt, the salt has to be stored parallel to the user entity
somewhere anyway.
I would like to know how to get access to the CredentialsMatcher and have it
generate the hashed password for me NOT when authenticating but at the time
the user registers.
In my opinion, the encoding scheme should be configured once, and the
CredentialsMatcher seems like the obvious place so I would like to use it
whenever I need to generate the hashed version of the password.
I'm thinking the only way to achieve this is to extend one of the
implementations of HashedCredentialsMatcher and expose a method which calls
'hashProvidedCredentials', and then add another method on the Realm to in
turn expose this feature.
This seems like a lot of effort and reduces the flexibility of the
architecture. For something that must be a common need and therefore should
be exposed by the API, so i'm wondering if I've missed some crucial feature.
Regards, paul.
On 11/11/2010 5:04 PM, Kalle Korhonen wrote:
On Wed, Nov 10, 2010 at 8:44 PM, Paul Stanton<p...@mapshed.com.au> wrote:
Firstly, I'd like to use a salted hash to match credentials... the
booking
example application does not do this and the documentation (for shiro)
doesn't quite show the complete picture.
Yeah I bet you are right on that. That should just work in my opinion
without end user having to do any extra work. But you are in luck with
that, kind of. 1.1.0 Shiro just added "built-in" support for
per-user-salt. tapestry-security 0.3.0-SNAPSHOT integrates with 1.1.0
Shiro and I'm going to cut the release pretty soon. See
http://www.mail-archive.com/d...@shiro.apache.org/msg00107.html and
http://svn.apache.org/repos/asf/shiro/trunk/core/src/test/java/org/apache/shiro/authc/credential/HashedCredentialsMatcherTest.java
for ideas).
How can I get a handle to an instance of my CredentialsMatcher and then
expose the method of hashing? should I make it a service too? I want to
get
a handle to it in 2 places:
1. at signup so i can persist the hashed password using the identical
hashing mechanism
2. in a database upgrade step so i can convert clear-text passwords into
the
hashed version
I think you should handle all of this as part of your realm
implementation with a custom AccountInfo. Not difficult to implement
but some amount of API learning to do. I've been fancying myself with
the idea of creating a tapestry-security-hibernate module with
prefabricated (JPA) entitities because it's just pointless to do the
same for every little webapp separately.
Why and how should I implement
AuthorizingRealm.doGetAuthorizationInfo(PrincipalCollection principals) ?
When would it be called in my basic application?
It'll be called right after doGetAuthentication() assuming it succeeds
if your realm promises to authorize users as well. A simple example is
that you could have a realm just to authenticate users against
Facebook, Google etc. while another realm would be responsible for
*authorizing* users using the permission information (roles etc)
stored in the local database. Often for a simpler webapp, you have
just a single realm which does both authentication and authorization.
Kalle
On 11/11/2010 2:29 AM, Kalle Korhonen wrote:
Ah you are looking for documentation on Shiro. Maybe I can place the
links to it more prominently on tapestry-security page, but see
http://shiro.apache.org/core.html (there's more but for now Subject
and Realms are the most relevant to you). If you want examples,
Christophe's hotel booking demo with Tynamo
(https://github.com/ccordenier/tapestry5-hotel-booking/tree/tynamo) is
very nice.
Kalle
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
