Probably in the library if it happens right after clicking on the link.
Kalle
On Thu, Aug 21, 2014 at 6:13 AM, George Christman <gchrist...@cardaddy.com>
wrote:
> For the time being I was able to somewhat get things working by adding the
> js to my local META-INF directory. When I clicked the facebook link I
> received a 400 error. Do you think this is a configuration error on my end,
> or do you think it maybe a side effect of it not working in 5.4? I guess it
> could also be a configuration issue within my facebook account too, I'm not
> really sure yet. What are your thoughts?
>
>
> On Thu, Aug 21, 2014 at 12:25 AM, Kalle Korhonen <
> kalle.o.korho...@gmail.com
> > wrote:
>
> > Unfortunately, I haven't updated federatedaccounts module to work with
> T5.4
> > yet. It's pretty simple as tapestry-security already supports T5.4 but
> will
> > be a week or two before I get to it because work's keeping me busy.
> Patches
> > welcome of course.
> >
> > Kalle
> >
> >
> > On Wed, Aug 20, 2014 at 4:53 PM, George Christman <
> gchrist...@cardaddy.com
> > >
> > wrote:
> >
> > > Hi Kalle, I'm getting the following exception,
> > >
> > >
> > >
> > > *Unable to locate asset 'OauthSignIn.js' for component
> > > registration/Signin:facebookoauthsignin. It should be located at
> > > META-INF/assets/federated/OauthSignIn.js.*
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > >
> > > *I'm using 5.4 and the following dependencies. Any thought why the
> > > OauthSignin.js might be missing? Thanks. <dependency>
> > > <groupId>org.tynamo</groupId>
> > > <artifactId>tapestry-security</artifactId>
> > > <version>0.5.1</version> </dependency><dependency>
> > > <groupId>org.tynamo.security</groupId>
> > > <artifactId>tynamo-federatedaccounts-facebook</artifactId>
> > > <version>0.4.3</version> </dependency>
> > > <dependency> <groupId>org.tynamo.security</groupId>
> > > <artifactId>tynamo-federatedaccounts-twitter</artifactId>
> > > <version>0.4.3</version> </dependency>
> > > <dependency> <groupId>org.tynamo.security</groupId>
> > > <artifactId>tynamo-federatedaccounts-pac4jbasedoauth</artifactId>
> > > <version>0.4.3</version> </dependency>*
> > >
> > >
> > > On Wed, Aug 20, 2014 at 12:45 AM, Kalle Korhonen <
> > > kalle.o.korho...@gmail.com
> > > > wrote:
> > >
> > > > 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
> > > > objects for a user who may or may not have been authenticated, such
> as
> > a
> > > > shopping cart or a simple user object caching the most important user
> > > > attributes as a performance optimization (in a database backed
> > > > environment). In the case of this sample, you want to create or
> update
> > > this
> > > > user object from data obtained by the remote authentication provider.
> > > >
> > > > Kalle
> > > >
> > > >
> > > > On Tue, Aug 19, 2014 at 7:38 PM, George Christman <
> > > gchrist...@cardaddy.com
> > > > >
> > > > wrote:
> > > >
> > > > > 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 where it takes currentUser. With that
> being
> > > > > commented out, I'm just not sure I understand how currentUser and
> the
> > > > merge
> > > > > are getting used.
> > > > >
> > > > >
> > > > > On Tue, Aug 19, 2014 at 7:48 PM, Kalle Korhonen <
> > > > > kalle.o.korho...@gmail.com>
> > > > > wrote:
> > > > >
> > > > > > 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
> > > > > > CurrentUser is with the example code and a sample implementation
> > for
> > > > > restfb
> > > > > > remote account is:
> > > > > > public void merge(com.restfb.types.User user) {
> > > > > > username = user.getName();
> > > > > > firstName = user.getFirstName();
> > > > > > lastName = user.getLastName();
> > > > > > }
> > > > > >
> > > > > > Any code example requires you to read the code but I'm not sure
> > how I
> > > > > could
> > > > > > change the code to highlight the possibilities better. Obviously,
> > > > what's
> > > > > > clear to me may not be so for others, so any suggestions for
> > > > improvements
> > > > > > are welcome.
> > > > > >
> > > > > > Kalle
> > > > > >
> > > > > >
> > > > > >
> > > > > > On Tue, Aug 19, 2014 at 2:32 PM, Chris Mylonas <
> ch...@opencsta.org
> > >
> > > > > wrote:
> > > > > >
> > > > > > > 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" <
> > gchrist...@cardaddy.com
> > > >
> > > > > > wrote:
> > > > > > >
> > > > > > > > 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" <
> > lance.j...@googlemail.com
> > > >
> > > > > > wrote:
> > > > > > > >
> > > > > > > > > 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" <
> > > > gchrist...@cardaddy.com
> > > > > >
> > > > > > > > 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 used before, so I was hoping someone
> > could
> > > > > > provide
> > > > > > > > > some
> > > > > > > > > > insight on what this code is actually doing and what the
> > > > purpose
> > > > > of
> > > > > > > > using
> > > > > > > > > > ApplicationStateManager is.
> > > > > > > > > >
> > > > > > > > > > Thanks,
> > > > > > > > > >
> > > > > > > > > >
> > > > > > > > > > --
> > > > > > > > > > George Christman
> > > > > > > > > > www.CarDaddy.com
> > > > > > > > > > P.O. Box 735
> > > > > > > > > > Johnstown, New York
> > > > > > > > > >
> > > > > > > > >
> > > > > > > >
> > > > > > >
> > > > > >
> > > > >
> > > > >
> > > > >
> > > > > --
> > > > > George Christman
> > > > > www.CarDaddy.com
> > > > > P.O. Box 735
> > > > > Johnstown, New York
> > > > >
> > > >
> > >
> > >
> > >
> > > --
> > > George Christman
> > > www.CarDaddy.com
> > > P.O. Box 735
> > > Johnstown, New York
> > >
> >
>
>
>
> --
> George Christman
> www.CarDaddy.com
> P.O. Box 735
> Johnstown, New York
>
