You are viewing a plain text version of this content. The canonical link for it is here.
Posted to users@tapestry.apache.org by Kalle Korhonen <ka...@gmail.com> on 2012/03/17 19:11:33 UTC

tapestry-security 0.4.3 released!

I swear, I thought tapestry-security already implemented anything you
need for security. But turns out I was wrong. So, we quickly put
together another, even more awesome release of tapestry-security for
Apache Tapestry 5 from http://tynamo.org, with the following
enhancements in the newly baked 0.4.3:

Bug

    [TYNAMO-124] - Context path duplicated when redirecting to saved request
    [TYNAMO-133] - ShiroHttpServletRequest isn't used if there's no
chain associated with the request

Improvement

    [TYNAMO-121] - Ability to plug into ExceptionPage for the same
exception type
    [TYNAMO-127] - Make SubjectFactory and RememberMeManager their own
services for better flexiblity

New Feature

    [TYNAMO-128] - Make Authenticator its own service to allow
registering authenticationlisteners

Check out the http://tynamo.org/tapestry-security+guide for more
information and enjoy!

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: tapestry-security 0.4.3 released!

Posted by Dimitris Zenios <di...@gmail.com>.
Cool.Will expect a patch release soon :)

On Wed, Mar 21, 2012 at 11:20 PM, Kalle Korhonen
<ka...@gmail.com> wrote:
> Yes.. https://jira.codehaus.org/browse/TYNAMO-145.
>
> Kalle
>
>
> On Wed, Mar 21, 2012 at 2:06 PM, Dimitris Zenios
> <di...@gmail.com> wrote:
>> I think there is a bug slipped in the latest 0.4.3 release.I get a
>> org.apache.shiro.subject.ExecutionException:
>> java.lang.IllegalStateException:
>> org.apache.shiro.session.InvalidSessionException:
>> java.lang.IllegalStateException
>>
>> when a user logouts from a page that has @RequiresRoles
>> annotation.This started happening at revision r2171.Full stack trace
>> below
>> 2012-03-22 01:06:30.035:WARN::/users.layout:logout
>> org.apache.shiro.subject.ExecutionException:
>> java.lang.IllegalStateException:
>> org.apache.shiro.session.InvalidSessionException:
>> java.lang.IllegalStateException
>>        at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:382)
>>        at org.tynamo.security.services.impl.SecurityConfiguration.service(SecurityConfiguration.java:104)
>>        at $HttpServletRequestFilter_81124445d4c.service(Unknown Source)
>>        at $HttpServletRequestHandler_81124445d51.service(Unknown Source)
>>        at org.apache.tapestry5.services.TapestryModule$1.service(TapestryModule.java:852)
>>        at $HttpServletRequestHandler_81124445d51.service(Unknown Source)
>>        at $HttpServletRequestHandler_81124445d4b.service(Unknown Source)
>>        at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:171)
>>        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>>        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
>>        at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>>        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>>        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
>>        at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
>>        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>>        at org.mortbay.jetty.Server.handle(Server.java:326)
>>        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>>        at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
>>        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
>>        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
>>        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>>        at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
>>        at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
>>
>> Regards
>> Dimitris Zenios
>>
>> On Mon, Mar 19, 2012 at 5:06 AM, trsvax <tr...@gmail.com> wrote:
>>> That's interesting. I did not know you could bind an abstract class instead
>>> of an interface.
>>>
>>> --
>>> View this message in context: http://tapestry.1045711.n5.nabble.com/tapestry-security-0-4-3-released-tp5574027p5576063.html
>>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>>
>>> ---------------------------------------------------------------------
>>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>>> For additional commands, e-mail: users-help@tapestry.apache.org
>>>
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: tapestry-security 0.4.3 released!

Posted by Kalle Korhonen <ka...@gmail.com>.
Yes.. https://jira.codehaus.org/browse/TYNAMO-145.

Kalle


On Wed, Mar 21, 2012 at 2:06 PM, Dimitris Zenios
<di...@gmail.com> wrote:
> I think there is a bug slipped in the latest 0.4.3 release.I get a
> org.apache.shiro.subject.ExecutionException:
> java.lang.IllegalStateException:
> org.apache.shiro.session.InvalidSessionException:
> java.lang.IllegalStateException
>
> when a user logouts from a page that has @RequiresRoles
> annotation.This started happening at revision r2171.Full stack trace
> below
> 2012-03-22 01:06:30.035:WARN::/users.layout:logout
> org.apache.shiro.subject.ExecutionException:
> java.lang.IllegalStateException:
> org.apache.shiro.session.InvalidSessionException:
> java.lang.IllegalStateException
>        at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:382)
>        at org.tynamo.security.services.impl.SecurityConfiguration.service(SecurityConfiguration.java:104)
>        at $HttpServletRequestFilter_81124445d4c.service(Unknown Source)
>        at $HttpServletRequestHandler_81124445d51.service(Unknown Source)
>        at org.apache.tapestry5.services.TapestryModule$1.service(TapestryModule.java:852)
>        at $HttpServletRequestHandler_81124445d51.service(Unknown Source)
>        at $HttpServletRequestHandler_81124445d4b.service(Unknown Source)
>        at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:171)
>        at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
>        at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
>        at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
>        at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
>        at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
>        at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
>        at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
>        at org.mortbay.jetty.Server.handle(Server.java:326)
>        at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
>        at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
>        at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
>        at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
>        at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
>        at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
>        at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)
>
> Regards
> Dimitris Zenios
>
> On Mon, Mar 19, 2012 at 5:06 AM, trsvax <tr...@gmail.com> wrote:
>> That's interesting. I did not know you could bind an abstract class instead
>> of an interface.
>>
>> --
>> View this message in context: http://tapestry.1045711.n5.nabble.com/tapestry-security-0-4-3-released-tp5574027p5576063.html
>> Sent from the Tapestry - User mailing list archive at Nabble.com.
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
>> For additional commands, e-mail: users-help@tapestry.apache.org
>>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: tapestry-security 0.4.3 released!

Posted by Dimitris Zenios <di...@gmail.com>.
I think there is a bug slipped in the latest 0.4.3 release.I get a
org.apache.shiro.subject.ExecutionException:
java.lang.IllegalStateException:
org.apache.shiro.session.InvalidSessionException:
java.lang.IllegalStateException

when a user logouts from a page that has @RequiresRoles
annotation.This started happening at revision r2171.Full stack trace
below
2012-03-22 01:06:30.035:WARN::/users.layout:logout
org.apache.shiro.subject.ExecutionException:
java.lang.IllegalStateException:
org.apache.shiro.session.InvalidSessionException:
java.lang.IllegalStateException
	at org.apache.shiro.subject.support.DelegatingSubject.execute(DelegatingSubject.java:382)
	at org.tynamo.security.services.impl.SecurityConfiguration.service(SecurityConfiguration.java:104)
	at $HttpServletRequestFilter_81124445d4c.service(Unknown Source)
	at $HttpServletRequestHandler_81124445d51.service(Unknown Source)
	at org.apache.tapestry5.services.TapestryModule$1.service(TapestryModule.java:852)
	at $HttpServletRequestHandler_81124445d51.service(Unknown Source)
	at $HttpServletRequestHandler_81124445d4b.service(Unknown Source)
	at org.apache.tapestry5.TapestryFilter.doFilter(TapestryFilter.java:171)
	at org.mortbay.jetty.servlet.ServletHandler$CachedChain.doFilter(ServletHandler.java:1212)
	at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:399)
	at org.mortbay.jetty.security.SecurityHandler.handle(SecurityHandler.java:216)
	at org.mortbay.jetty.servlet.SessionHandler.handle(SessionHandler.java:182)
	at org.mortbay.jetty.handler.ContextHandler.handle(ContextHandler.java:766)
	at org.mortbay.jetty.webapp.WebAppContext.handle(WebAppContext.java:450)
	at org.mortbay.jetty.handler.HandlerWrapper.handle(HandlerWrapper.java:152)
	at org.mortbay.jetty.Server.handle(Server.java:326)
	at org.mortbay.jetty.HttpConnection.handleRequest(HttpConnection.java:542)
	at org.mortbay.jetty.HttpConnection$RequestHandler.headerComplete(HttpConnection.java:928)
	at org.mortbay.jetty.HttpParser.parseNext(HttpParser.java:549)
	at org.mortbay.jetty.HttpParser.parseAvailable(HttpParser.java:212)
	at org.mortbay.jetty.HttpConnection.handle(HttpConnection.java:404)
	at org.mortbay.io.nio.SelectChannelEndPoint.run(SelectChannelEndPoint.java:410)
	at org.mortbay.thread.QueuedThreadPool$PoolThread.run(QueuedThreadPool.java:582)

Regards
Dimitris Zenios

On Mon, Mar 19, 2012 at 5:06 AM, trsvax <tr...@gmail.com> wrote:
> That's interesting. I did not know you could bind an abstract class instead
> of an interface.
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/tapestry-security-0-4-3-released-tp5574027p5576063.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: tapestry-security 0.4.3 released!

Posted by trsvax <tr...@gmail.com>.
That's interesting. I did not know you could bind an abstract class instead
of an interface.

--
View this message in context: http://tapestry.1045711.n5.nabble.com/tapestry-security-0-4-3-released-tp5574027p5576063.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: tapestry-security 0.4.3 released!

Posted by Kalle Korhonen <ka...@gmail.com>.
On Sun, Mar 18, 2012 at 3:41 PM, trsvax <tr...@gmail.com> wrote:
> I guess I've just gotten in the habit of making everything a service with an
> Interface. Class reloading without a restart is pretty handy, but in this

Of course, you can make it a service, you just don't need to. If you
nevertheless do, you need to make sure that you make your realm is
known to Tapestry with the right interface, e.g:
binder.bind(AuthorizingRealm.class, UserRealm.class);

Compare http://svn.codehaus.org/tynamo/trunk/tynamo-federatedaccounts/tynamo-federatedaccounts-core/src/test/java/org/tynamo/security/federatedaccounts/testapp/services/AppModule.java
to yours.

> case you are correct the following is the way to go:
> public static void contributeWebSecurityManager(Configuration<Realm>
> configuration, UserDAO userDAO) {
>     configuration.add(new UserRealm(userDAO));
> }

They are all correct, but I'd write it as:
public static void contributeWebSecurityManager(Configuration<Realm>
configuration, @Autobuild UserRealm userRealm) {
    configuration.add(userRealm);
}

Kalle

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: tapestry-security 0.4.3 released!

Posted by trsvax <tr...@gmail.com>.
I guess I've just gotten in the habit of making everything a service with an
Interface. Class reloading without a restart is pretty handy, but in this
case you are correct the following is the way to go:

public static void contributeWebSecurityManager(Configuration<Realm>
configuration, UserDAO userDAO) {
     configuration.add(new UserRealm(userDAO));
}



--
View this message in context: http://tapestry.1045711.n5.nabble.com/tapestry-security-0-4-3-released-tp5574027p5575788.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: tapestry-security 0.4.3 released!

Posted by Kalle Korhonen <ka...@gmail.com>.
On Sun, Mar 18, 2012 at 2:43 PM, trsvax <tr...@gmail.com> wrote:
> I see what the problem is although now I not sure why it works at all. I have
> this in my AppModule
> binder.bind(Realm.class, UserRealm.class);
> public static void contributeWebSecurityManager(Configuration<Realm>
> configuration, Realm userRealm) {
>                configuration.add(userRealm);
> }
> but the Realm interface does not contain
> AuthorizationInfo doGetAuthorizationInfo
> When I change to this
>  binder.bind(UserRealm.class);
> everything works. I looked thru the Shiro docs and there does not seem to be
> an interface that contains AuthorizationInfo doGetAuthorizationInfo

AuthorizingRealm does. But of course, should have figured that out -
basically the securitymanager doesn't see the realm is an
authorizingrealm. Ask yourself, does your realm really need to be a
service? Especially given how trivial it is to inject your realm
instances with @Autobuild to your SecurityManager contributions
operation. Anyway, it's certainly something I need to highlight in the
docs, others can easily trip on the same as well.

Kalle

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: tapestry-security 0.4.3 released!

Posted by trsvax <tr...@gmail.com>.
I see what the problem is although now I not sure why it works at all. I have
this in my AppModule


binder.bind(Realm.class, UserRealm.class);

and 

public static void contributeWebSecurityManager(Configuration<Realm>
configuration, Realm userRealm) {
		configuration.add(userRealm);
}

but the Realm interface does not contain

AuthorizationInfo doGetAuthorizationInfo

When I change to this

 binder.bind(UserRealm.class);

everything works. I looked thru the Shiro docs and there does not seem to be
an interface that contains AuthorizationInfo doGetAuthorizationInfo



--
View this message in context: http://tapestry.1045711.n5.nabble.com/tapestry-security-0-4-3-released-tp5574027p5575699.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: tapestry-security 0.4.3 released!

Posted by trsvax <tr...@gmail.com>.
Tried 0.4.1 and I have the same problem. I'll see if I can track it down and
report back.

--
View this message in context: http://tapestry.1045711.n5.nabble.com/tapestry-security-0-4-3-released-tp5574027p5575350.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: tapestry-security 0.4.3 released!

Posted by Kalle Korhonen <ka...@gmail.com>.
On Sun, Mar 18, 2012 at 6:56 AM, trsvax <tr...@gmail.com> wrote:
> Thanks for the update but when I upgraded from 0.4.0 I can authenticate but
> my roles quit working. When I run the app in debug mode it appears
> protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection
> principals)
> in my UserRealm is not called. It does get called in 0.4.0. My UserRealm is
> basically a copy of the Hibernate realm in your example.

0.4.0 was still using Shiro 1.1.0 whereas the latter ones are using
1.2.0, so it's likely related to that. One of the main differences was
that AuthenticatingRealm doesn't anymore implement Authorizer
interface, and otherwise I would have assumed that's the problem but
your Realm below clearly does implement AuthorizingRealm. Don't have
any other likely causes off the top of my hat and many of the
integration tests utilize roles without problems. Suppose you could
test against 0.4.1  just to isolate the problem further but I'm pretty
sure you get the same result. If you swap Shiro 1.1.0 back in
(tapestry-security doesn't use anything 1.2 specific) do things work?

Kalle


> public class UserRealm extends AuthorizingRealm {
>        private final UserDAO userDAO;
>
>        public UserRealm(UserDAO userDAO) {
>                super(new MemoryConstrainedCacheManager());
>                setName("localaccounts");
>                setAuthenticationTokenClass(UsernamePasswordToken.class);
>                setCredentialsMatcher(new
> HashedCredentialsMatcher(Sha1Hash.ALGORITHM_NAME));
>                this.userDAO = userDAO;
>        }
>
>
>        @Override
>        protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection
> principals) {
>                if (principals == null) throw new
> AuthorizationException("PrincipalCollection was null, which should not
> happen");
>
>                if (principals.isEmpty()) return null;
>
>                if (principals.fromRealm(getName()).size() <= 0) return null;
>
>                String username = (String)
> principals.fromRealm(getName()).iterator().next();
>                if (username == null) return null;
>                User user = findByUsername(username);
>                if (user == null) return null;
>                return new SimpleAuthorizationInfo(user.getRoles());
>        }
>
>        private User findByUsername(String username) {
>                return userDAO.load(username);
>        }
>
>        @Override
>        protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken
> token) throws AuthenticationException {
>                UsernamePasswordToken upToken = (UsernamePasswordToken) token;
>
>                String username = upToken.getUsername();
>
>                // Null username is invalid
>                if (username == null) { throw new AccountException("Null usernames are not
> allowed by this realm."); }
>
>                User user = findByUsername(username);
>                if (user.getFacebookUserId() != null) { throw new
> AccountException("Account [" + username
>                                + "] is federated with Facebook and cannot be locally authenticated.");
> }
>
>                if (user.isAccountLocked()) { throw new LockedAccountException("Account ["
> + username + "] is locked."); }
>                if (user.isCredentialsExpired()) {
>                        String msg = "The credentials for account [" + username + "] are
> expired";
>                        throw new ExpiredCredentialsException(msg);
>                }
>                return new SimpleAuthenticationInfo(username, user.getEncodedPassword(),
>                                new SimpleByteSource(user.getPasswordSaltBytes()), getName());
>        }
>
> }
>
>
> I looked thru the docs but I did not see anything that might cause this. Did
> I miss something?
>
> Thanks
> Barry
>
>
> --
> View this message in context: http://tapestry.1045711.n5.nabble.com/tapestry-security-0-4-3-released-tp5574027p5575021.html
> Sent from the Tapestry - User mailing list archive at Nabble.com.
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
> For additional commands, e-mail: users-help@tapestry.apache.org
>

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org


Re: tapestry-security 0.4.3 released!

Posted by trsvax <tr...@gmail.com>.
Thanks for the update but when I upgraded from 0.4.0 I can authenticate but
my roles quit working. When I run the app in debug mode it appears 

protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection
principals) 

in my UserRealm is not called. It does get called in 0.4.0. My UserRealm is
basically a copy of the Hibernate realm in your example. 

public class UserRealm extends AuthorizingRealm {
	private final UserDAO userDAO;
	
	public UserRealm(UserDAO userDAO) {
		super(new MemoryConstrainedCacheManager());
		setName("localaccounts");
		setAuthenticationTokenClass(UsernamePasswordToken.class);
		setCredentialsMatcher(new
HashedCredentialsMatcher(Sha1Hash.ALGORITHM_NAME));
		this.userDAO = userDAO;
	}


	@Override
	protected AuthorizationInfo doGetAuthorizationInfo(PrincipalCollection
principals) {
		if (principals == null) throw new
AuthorizationException("PrincipalCollection was null, which should not
happen");

		if (principals.isEmpty()) return null;

		if (principals.fromRealm(getName()).size() <= 0) return null;

		String username = (String)
principals.fromRealm(getName()).iterator().next();
		if (username == null) return null;
		User user = findByUsername(username);
		if (user == null) return null;
		return new SimpleAuthorizationInfo(user.getRoles());
	}

	private User findByUsername(String username) {
		return userDAO.load(username);
	}

	@Override
	protected AuthenticationInfo doGetAuthenticationInfo(AuthenticationToken
token) throws AuthenticationException {
		UsernamePasswordToken upToken = (UsernamePasswordToken) token;

		String username = upToken.getUsername();

		// Null username is invalid
		if (username == null) { throw new AccountException("Null usernames are not
allowed by this realm."); }

		User user = findByUsername(username);
		if (user.getFacebookUserId() != null) { throw new
AccountException("Account [" + username
				+ "] is federated with Facebook and cannot be locally authenticated.");
}

		if (user.isAccountLocked()) { throw new LockedAccountException("Account ["
+ username + "] is locked."); }
		if (user.isCredentialsExpired()) {
			String msg = "The credentials for account [" + username + "] are
expired";
			throw new ExpiredCredentialsException(msg);
		}
		return new SimpleAuthenticationInfo(username, user.getEncodedPassword(), 
				new SimpleByteSource(user.getPasswordSaltBytes()), getName());
	}

}


I looked thru the docs but I did not see anything that might cause this. Did
I miss something?

Thanks
Barry


--
View this message in context: http://tapestry.1045711.n5.nabble.com/tapestry-security-0-4-3-released-tp5574027p5575021.html
Sent from the Tapestry - User mailing list archive at Nabble.com.

---------------------------------------------------------------------
To unsubscribe, e-mail: users-unsubscribe@tapestry.apache.org
For additional commands, e-mail: users-help@tapestry.apache.org