Re: tynamo tapestry-security help
Thanks Everton! With a high certainty, that's the root cause. Perhaps I'll just document this for now, wonder if T5.1.0.8 release will see the light of the day at some point. Kalle On Wed, Nov 17, 2010 at 8:32 AM, Everton Agner wrote: > 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 > >> 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 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 >> 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 >> > 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
Re: tynamo tapestry-security help
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 > 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 > > 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 >> 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 >> 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 >> > 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 >>
Re: tynamo tapestry-security help
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 > 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 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 > 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 > > 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 > >>> wrote: > > Kalle, > > I thi
Re: tynamo tapestry-security help
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 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 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 > 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 >>> 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
Re: tynamo tapestry-security help
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 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 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 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 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 us
Re: tynamo tapestry-security help
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 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 >>> 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 > 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 >>> wrote: >>
Re: tynamo tapestry-security help
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 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 Stantonwrote: 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 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 p
Re: tynamo tapestry-security help
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 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 Stantonwrote: 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 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 im
Re: tynamo tapestry-security help
On Thu, Nov 11, 2010 at 2:25 PM, Paul Stanton 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 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 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 im
Re: tynamo tapestry-security help
Hi Kalle, Interesting. You can see the need for the behaviour but not the need to expose/implement it cleanly via the API. 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 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 Stantonwrote: 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
Re: tynamo tapestry-security help
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 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 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: user
Re: tynamo tapestry-security help
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 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
Re: tynamo tapestry-security help
On Wed, Nov 10, 2010 at 8:44 PM, Paul Stanton 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
Re: tynamo tapestry-security help
Hi Kalle, Thanks for the extra information, yes I was looking for that type of documentation and the example app has helped my understanding. I still have a couple of questions though... 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. 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 Why and how should I implement AuthorizingRealm.doGetAuthorizationInfo(PrincipalCollection principals) ? When would it be called in my basic application? i might have more questions later . ;) cheers, paul. 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
Re: tynamo tapestry-security help
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 On Tue, Nov 9, 2010 at 8:46 PM, Paul Stanton wrote: > hi kalle, > > ok, to start with.. > > how would you go about integrating a userset stored in a database? > > how do you replace/customise the login page? > > how do you manually perform authentication? > > cheers, p. > > On 10/11/2010 3:17 PM, Kalle Korhonen wrote: >> >> On Tue, Nov 9, 2010 at 7:57 PM, Paul Stanton wrote: >>> >>> Anyone know of a good 'getting started' guide for tynamo >>> tapestry-security? >>> this one ... >>> http://docs.codehaus.org/display/TYNAMO/tapestry-security+guide >>> ... still leaves me scratching my head. >> >> It does? Sorry about that, I honestly thought it's pretty >> straight-forwarded. What do you feel is missing? >> >> We have pretty extensive integration tests with the module, maybe >> taking a look at them would help you. You could start from >> >> http://svn.codehaus.org/tynamo/trunk/tapestry-security/src/test/java/org/tynamo/security/testapp/services/AppModule.java >> >> 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
Re: tynamo tapestry-security help
hi kalle, ok, to start with.. how would you go about integrating a userset stored in a database? how do you replace/customise the login page? how do you manually perform authentication? cheers, p. On 10/11/2010 3:17 PM, Kalle Korhonen wrote: On Tue, Nov 9, 2010 at 7:57 PM, Paul Stanton wrote: Anyone know of a good 'getting started' guide for tynamo tapestry-security? this one ... http://docs.codehaus.org/display/TYNAMO/tapestry-security+guide ... still leaves me scratching my head. It does? Sorry about that, I honestly thought it's pretty straight-forwarded. What do you feel is missing? We have pretty extensive integration tests with the module, maybe taking a look at them would help you. You could start from http://svn.codehaus.org/tynamo/trunk/tapestry-security/src/test/java/org/tynamo/security/testapp/services/AppModule.java 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
Re: tynamo tapestry-security help
On Tue, Nov 9, 2010 at 7:57 PM, Paul Stanton wrote: > Anyone know of a good 'getting started' guide for tynamo tapestry-security? > this one ... > http://docs.codehaus.org/display/TYNAMO/tapestry-security+guide > ... still leaves me scratching my head. It does? Sorry about that, I honestly thought it's pretty straight-forwarded. What do you feel is missing? We have pretty extensive integration tests with the module, maybe taking a look at them would help you. You could start from http://svn.codehaus.org/tynamo/trunk/tapestry-security/src/test/java/org/tynamo/security/testapp/services/AppModule.java Kalle - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org
tynamo tapestry-security help
Anyone know of a good 'getting started' guide for tynamo tapestry-security? this one ... http://docs.codehaus.org/display/TYNAMO/tapestry-security+guide ... still leaves me scratching my head. thanks, p. - To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org For additional commands, e-mail: users-h...@tapestry.apache.org