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
