Btw, as a Workaround, you can make a ComponentRequestFilter that redirects
to the Start page when the url root path ("/yourapp/") is requested. That
would make it work._______________________ Everton Agner Ramos 2010/11/17 Everton Agner <ton.ag...@gmail.com> > You might be facing the TAP5-1018 Bug i've reported... > https://issues.apache.org/jira/browse/TAP5-1018 > > _______________________ > Everton Agner Ramos > > > 2010/11/17 Kalle Korhonen <kalle.o.korho...@gmail.com> > > 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.htmland >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> >>>>>>>>> >> 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 >> >> >
