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
