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
