On Thu, Nov 11, 2010 at 2:25 PM, Paul Stanton <p...@mapshed.com.au> wrote:
> Interesting. You can see the need for the behaviour but not the need to
> expose/implement it cleanly via the API.
No, that's the wrong conclusion. Subscribe to the shiro dev list, we
recently had extensive discussion on this but in the meantime I'm
saying that you should do and I have done whatever I needed for my
current needs.
Kalle
> 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
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
For additional commands, e-mail: users-h...@tapestry.apache.org
