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
>
>
