It's all sample code for typical use cases. For authentication, you need to
have (or Shiro needs to have) an AuthenticationInfo in session. That's
where the principals and the credentials tokens are stored. Separately, in
your Tapestry application, you may have several (preferably light) session
ob
I think where I was confused was coming at this with the idea of having a
database backed environment. I see your comments in CurrentUser.class
about ApplicationStateCreator
although I still don't fully understand it. I also seen some code where you
were commenting out
SimpleAuthenticationInfo wher
The examples lack comments because I strongly believe in self-documenting
code. FederatedAccountService.federate() is the core concept of the
federated account module. Federated accounts module allows you to federate
(i.e. join, merge) separate accounts together. The implementation of this
CurrentU
CurrentUser.class
Its a get method, probably on a hashtable-like object. Getting current
user.
The auth token is probably from the oauth2 provider like fb or gg.
With the current user and this token, merge them in *your* app.
/guessing
On 20/08/2014 7:05 am, "George Christman" wrote:
> I gue
I guess I'm not following the logic of the code then. Why would they be
passing CurrentUser into it then?
On Aug 19, 2014 4:46 PM, "Lance Java" wrote:
> The ApplicationStateManager is a core Tapestry service and is an
> abstraction over HttpSession persistence. As stated in the javadocs
> Applica
The ApplicationStateManager is a core Tapestry service and is an
abstraction over HttpSession persistence. As stated in the javadocs
Application state is probably a bad choice of naming. In hindsight it
should probably be called SessionStateManager.
On 19 Aug 2014 21:04, "George Christman" wrote:
Hi guys, I see this example of ApplicationStateManager being used with the
federatedaccounts example. line 20
https://github.com/tynamo/tynamo-example-federatedaccounts/blob/master/src/main/java/org/tynamo/examples/federatedaccounts/services/FederatedAccountServiceExample.java
I've never seen it
Why not add a html class or a data- attribute to the zones which need
overlays. You can then test for the flag then test for the flag before
showing / hiding the overlay?
