Wonder if Start is handled differently than Index - if you can, please
check and open (Tynamo) issue accordingly.
Kalle
On Wed, Nov 17, 2010 at 1:44 AM, Paul Stanton <p...@mapshed.com.au> wrote:
> Hi Kalle,
>
> I've just tried t-s 0.2.1 and the
> org.apache.shiro.authz.annotation.RequiresAuthentication annotation.
>
> package zzz.pages;
>
> @RequiresAuthentication
> public class Start
> {}
>
> The same problem occurs.
> http://host/app/start - correctly directs to the login page
> http://host/app/ - incorrectly displays the page content
>
> regards, paul.
>
>
> On 16/11/2010 11:50 AM, Kalle Korhonen wrote:
>>
>> Move to tapestry-security 0.2.1 and use the Shiro
>> @RequiresAuthentication annotation instead. The *All annotations were
>> removed since I implemented them in Shiro directly (one of the
>> benefits of being a committer in both). We do have a couple of tests
>> for the case and those are passing. There's a possibility that it was
>> an issue with Shiro 1.0.0-incubating release.
>>
>> Kalle
>>
>>
>> On Sat, Nov 13, 2010 at 2:28 PM, Paul Stanton<p...@mapshed.com.au> wrote:
>>>
>>> Also,
>>>
>>> I've marked my 'Start' page as @RequiresAuthenticationAll, and it
>>> correctly
>>> forwards to the login page when not already authenticated if the url is
>>>
>>> http://host/app/start
>>>
>>> however it displays the page's content if the url is
>>>
>>> http://host/app/
>>>
>>> This appears to be a bug IMO, is there a way to work around this or
>>> should I
>>> log an issue?
>>>
>>> p.
>>>
>>> On 12/11/2010 10:50 PM, Paul Stanton wrote:
>>>>
>>>> Kalle,
>>>>
>>>> Leaving that one behind...
>>>>
>>>> Where can I find the documentation regarding the various tapestry
>>>> components and pages provided by tapestry-security?
>>>>
>>>> The Javadoc only contains explainations for 5/11 of the components:
>>>>
>>>> http://tynamo.org/constant/tapestry-security/apidocs/index.html
>>>>
>>>> Also, is there a SVN i can download the source code from?
>>>>
>>>> regards, Paul.
>>>>
>>>> On 12/11/2010 10:56 AM, Kalle Korhonen wrote:
>>>>>
>>>>> 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
>>>>>
>>>>>
>>>> ---------------------------------------------------------------------
>>>> 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
