Re: Tynamo Security Login Page

2016-11-09 Thread Kalle Korhonen
Need to specify the library since it's not your own component - loginPage
is just a local attribute name. Use  or
just replace the whole block with <:tsecurity.loginlink>.

Kalle

On Wed, Nov 9, 2016 at 9:03 AM, Adam X  wrote:

> I have tapestry-security integrated and working in my project. Page
> classes annotated with shiro such as @RequiresAuthentication get
> intercepted with the login page.
>
> What is the best way to create a link on my page that redirects to tap
> security login page?
>
> In my Laout.java I tried this:
>
> @Property
> @Inject
> private SecurityService securityService;
>
> @Property
> @InjectPage
> private org.tynamo.security.pages.Login loginPage;
>
> then in my Layout.tml I have this:
>
> 
>   ${securityService.subject.principal}
>   
> Guest (Sign In)
>   
> 
>
> But Tapestry is unable to find this Tynamo page, even though it is
> clearly there:
>
> Caused by: org.apache.tapestry5.ioc.util.UnknownValueException: Unable
> to resolve 'loginPage' to a known page name
>
> What is the accepted (or recommended) way to bring up the login page
> in such a setup?
>
> -
> To unsubscribe, e-mail: users-unsubscr...@tapestry.apache.org
> For additional commands, e-mail: users-h...@tapestry.apache.org
>
>


Tynamo Security Login Page

2016-11-09 Thread Adam X
I have tapestry-security integrated and working in my project. Page
classes annotated with shiro such as @RequiresAuthentication get
intercepted with the login page.

What is the best way to create a link on my page that redirects to tap
security login page?

In my Laout.java I tried this:

@Property
@Inject
private SecurityService securityService;

@Property
@InjectPage
private org.tynamo.security.pages.Login loginPage;

then in my Layout.tml I have this:


  ${securityService.subject.principal}
  
Guest (Sign In)
  


But Tapestry is unable to find this Tynamo page, even though it is
clearly there:

Caused by: org.apache.tapestry5.ioc.util.UnknownValueException: Unable
to resolve 'loginPage' to a known page name

What is the accepted (or recommended) way to bring up the login page
in such a setup?

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



Re: Tynamo Security w/ custom Realm

2016-11-09 Thread Adam X
Hello All - just want to say everything in Shiro was configured ok.
The bug was in the implementation of my mock dao.

All works nicely

On Wed, Nov 9, 2016 at 2:49 PM, Adam X  wrote:
> So I set org.apache.shiro to DEBUG level and discovered that Shiro is
> actually correctly authenticating but for some reason displays
> "Unauthorized" page:
>
> [DEBUG] com.foo.bar.core.engine.components.dao.UserManagementMockDao
> (getUser:444) - userId: donkey
> [DEBUG] com.foo.bar.core.engine.components.dao.UserManagementMockDao
> (getUserPassword:451) - userId: donkey
> [DEBUG] org.apache.shiro.realm.AuthenticatingRealm
> (getAuthenticationInfo:569) - Looked up AuthenticationInfo [donkey]
> from doGetAuthenticationInfo
> [DEBUG] org.apache.shiro.realm.AuthenticatingRealm
> (cacheAuthenticationInfoIfPossible:507) - AuthenticationInfo caching
> is disabled for info [donkey].  Submitted token:
> [org.apache.shiro.authc.UsernamePasswordToken - donkey,
> rememberMe=false].
> [DEBUG] org.apache.shiro.authc.credential.SimpleCredentialsMatcher
> (equals:95) - Performing credentials equality check for
> tokenCredentials of type [[C and accountCredentials of type
> [java.lang.String]
> [DEBUG] org.apache.shiro.authc.credential.SimpleCredentialsMatcher
> (equals:101) - Both credentials arguments can be easily converted to
> byte arrays.  Performing array equals comparison
> [DEBUG] org.apache.shiro.authc.AbstractAuthenticator
> (authenticate:233) - Authentication successful for token
> [org.apache.shiro.authc.UsernamePasswordToken - donkey,
> rememberMe=false].  Returned account [donkey]
> [DEBUG] org.apache.shiro.subject.support.DefaultSubjectContext
> (resolveSecurityManager:102) - No SecurityManager available in subject
> context map.  Falling back to SecurityUtils.getSecurityManager()
> lookup.
> [DEBUG] org.apache.shiro.subject.support.DefaultSubjectContext
> (resolveSecurityManager:102) - No SecurityManager available in subject
> context map.  Falling back to SecurityUtils.getSecurityManager()
> lookup.
> [DEBUG] org.apache.shiro.web.servlet.SimpleCookie
> (addCookieHeader:226) - Added HttpServletResponse Cookie
> [rememberMe=deleteMe; Path=/bip; Max-Age=0; Expires=Tue, 08-Nov-2016
> 12:28:52 GMT]
> [DEBUG] org.apache.shiro.mgt.AbstractRememberMeManager
> (onSuccessfulLogin:290) - AuthenticationToken did not indicate
> RememberMe is requested.  RememberMe functionality will not be
> executed for corresponding account.
> [DEBUG] org.apache.shiro.realm.AuthorizingRealm
> (getAuthorizationCacheLazy:234) - No authorizationCache instance set.
> Checking for a cacheManager...
> [DEBUG] org.apache.shiro.realm.AuthorizingRealm
> (getAuthorizationCacheLazy:242) - CacheManager
> [MemoryConstrainedCacheManager with 0 cache(s)): []] has been
> configured.  Building authorization cache named
> [awsiamaccounts.authorizationCache]
>
> So I must have a misconfiguration somewhere but am stuck as I can't
> figure out where. I just thought that tapestry-security automagically
> handles redirect after login. My page is very simple:
>
> @RequiresRoles("administrator")
> public class Contact {
> }
>
>
> On Tue, Nov 8, 2016 at 8:30 PM, Adam X  wrote:
>> Hi Kyle,
>>
>> Thanks for taking a look. Indeed, I made the assumption that
>> SimpleCredentialsMatcher is used by default, but as part of my
>> troubleshooting I explicitly set it. doGetAuthenticationInfo is
>> invoked for sure, because my logs show it (I also stepped thru with
>> the debugger):
>>
>> [WARN] org.tynamo.security.services.SecurityModule.RememberMeManager
>> (buildRememberMeManager:111) - Symbol 'security.remembermecipherkey'
>> is not set, using 'tapestry.hmac-passphrase' as the cipher. Beware
>> that changing the value will invalidate rememberMe cookies
>> [ERROR] org.apache.tapestry5.modules.AssetsModule.AssetSource
>> (invoke:237) - Packaging of classpath assets has changed in release
>> 5.4; Assets should no longer be on the main classpath, but should be
>> moved to 'META-INF/assets/' or a sub-folder. Future releases of
>> Tapestry may no longer support assets on the main classpath.
>> [WARN] org.apache.tapestry5.modules.AssetsModule.AssetSource
>> (invoke:245) - Classpath asset '/org/tynamo/security/img/login-bg.png'
>> should be moved to folder
>> '/META-INF/assets/security/org/tynamo/security/img/'.
>> [DEBUG] com.foo.bar.core.engine.components.dao.UserManagementMockDao
>> (getUser:444) - userId: donkey
>> [DEBUG] com.foo.bar.core.engine.components.dao.UserManagementMockDao
>> (getUserPassword:451) - userId: donkey
>>
>> As you can see my mock dao is correctly being called and it is
>> returning the correct password because I saw it in the debugger.
>>
>> Am I instantiating SimpleAuthenticationInfo correctly? This API is all
>> new to me (never worked with Shiro) so I'm learning as I go.
>>
>> Also, here is what my AppModule contribution looks like:
>>
>> @Contribute(WebSecurityManager.class)
>> public static void addRealms(Configuration configuration,
>> @Inject @Fr

Re: Tynamo Security w/ custom Realm

2016-11-09 Thread Adam X
So I set org.apache.shiro to DEBUG level and discovered that Shiro is
actually correctly authenticating but for some reason displays
"Unauthorized" page:

[DEBUG] com.foo.bar.core.engine.components.dao.UserManagementMockDao
(getUser:444) - userId: donkey
[DEBUG] com.foo.bar.core.engine.components.dao.UserManagementMockDao
(getUserPassword:451) - userId: donkey
[DEBUG] org.apache.shiro.realm.AuthenticatingRealm
(getAuthenticationInfo:569) - Looked up AuthenticationInfo [donkey]
from doGetAuthenticationInfo
[DEBUG] org.apache.shiro.realm.AuthenticatingRealm
(cacheAuthenticationInfoIfPossible:507) - AuthenticationInfo caching
is disabled for info [donkey].  Submitted token:
[org.apache.shiro.authc.UsernamePasswordToken - donkey,
rememberMe=false].
[DEBUG] org.apache.shiro.authc.credential.SimpleCredentialsMatcher
(equals:95) - Performing credentials equality check for
tokenCredentials of type [[C and accountCredentials of type
[java.lang.String]
[DEBUG] org.apache.shiro.authc.credential.SimpleCredentialsMatcher
(equals:101) - Both credentials arguments can be easily converted to
byte arrays.  Performing array equals comparison
[DEBUG] org.apache.shiro.authc.AbstractAuthenticator
(authenticate:233) - Authentication successful for token
[org.apache.shiro.authc.UsernamePasswordToken - donkey,
rememberMe=false].  Returned account [donkey]
[DEBUG] org.apache.shiro.subject.support.DefaultSubjectContext
(resolveSecurityManager:102) - No SecurityManager available in subject
context map.  Falling back to SecurityUtils.getSecurityManager()
lookup.
[DEBUG] org.apache.shiro.subject.support.DefaultSubjectContext
(resolveSecurityManager:102) - No SecurityManager available in subject
context map.  Falling back to SecurityUtils.getSecurityManager()
lookup.
[DEBUG] org.apache.shiro.web.servlet.SimpleCookie
(addCookieHeader:226) - Added HttpServletResponse Cookie
[rememberMe=deleteMe; Path=/bip; Max-Age=0; Expires=Tue, 08-Nov-2016
12:28:52 GMT]
[DEBUG] org.apache.shiro.mgt.AbstractRememberMeManager
(onSuccessfulLogin:290) - AuthenticationToken did not indicate
RememberMe is requested.  RememberMe functionality will not be
executed for corresponding account.
[DEBUG] org.apache.shiro.realm.AuthorizingRealm
(getAuthorizationCacheLazy:234) - No authorizationCache instance set.
Checking for a cacheManager...
[DEBUG] org.apache.shiro.realm.AuthorizingRealm
(getAuthorizationCacheLazy:242) - CacheManager
[MemoryConstrainedCacheManager with 0 cache(s)): []] has been
configured.  Building authorization cache named
[awsiamaccounts.authorizationCache]

So I must have a misconfiguration somewhere but am stuck as I can't
figure out where. I just thought that tapestry-security automagically
handles redirect after login. My page is very simple:

@RequiresRoles("administrator")
public class Contact {
}


On Tue, Nov 8, 2016 at 8:30 PM, Adam X  wrote:
> Hi Kyle,
>
> Thanks for taking a look. Indeed, I made the assumption that
> SimpleCredentialsMatcher is used by default, but as part of my
> troubleshooting I explicitly set it. doGetAuthenticationInfo is
> invoked for sure, because my logs show it (I also stepped thru with
> the debugger):
>
> [WARN] org.tynamo.security.services.SecurityModule.RememberMeManager
> (buildRememberMeManager:111) - Symbol 'security.remembermecipherkey'
> is not set, using 'tapestry.hmac-passphrase' as the cipher. Beware
> that changing the value will invalidate rememberMe cookies
> [ERROR] org.apache.tapestry5.modules.AssetsModule.AssetSource
> (invoke:237) - Packaging of classpath assets has changed in release
> 5.4; Assets should no longer be on the main classpath, but should be
> moved to 'META-INF/assets/' or a sub-folder. Future releases of
> Tapestry may no longer support assets on the main classpath.
> [WARN] org.apache.tapestry5.modules.AssetsModule.AssetSource
> (invoke:245) - Classpath asset '/org/tynamo/security/img/login-bg.png'
> should be moved to folder
> '/META-INF/assets/security/org/tynamo/security/img/'.
> [DEBUG] com.foo.bar.core.engine.components.dao.UserManagementMockDao
> (getUser:444) - userId: donkey
> [DEBUG] com.foo.bar.core.engine.components.dao.UserManagementMockDao
> (getUserPassword:451) - userId: donkey
>
> As you can see my mock dao is correctly being called and it is
> returning the correct password because I saw it in the debugger.
>
> Am I instantiating SimpleAuthenticationInfo correctly? This API is all
> new to me (never worked with Shiro) so I'm learning as I go.
>
> Also, here is what my AppModule contribution looks like:
>
> @Contribute(WebSecurityManager.class)
> public static void addRealms(Configuration configuration,
> @Inject @FromFactory UserManagementDao dao) {
> Realm realm = new FooBarCoreRealm(dao);
> configuration.add(realm);
> }
>
> Obviously replaced company name with FooBar etc.
>
> Adam
>
> On Tue, Nov 8, 2016 at 7:55 PM, Kalle Korhonen
>  wrote:
>> Looks fine at a quick glance. As I recall, an AuthenticatingRealm uses
>> SimpleCrede