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
