socialauth - can you use same session across a redirect?

Question

I'm trying to use socialauth to login with google, facebook et al (I'll assume google here) and have a question about how it works. I'm using JSF 2 without Seam. The basic idea is that you:

• make a few API calls indicating that you want to login with google.

• make another API call which returns a URL for google.

• supply a result URL which will be used by google to redirect back to your site.

• redirect to the google URL.

• then google will either immediately redirect back to your site or first ask for login details.

My confusion is about linking together the data from the outbound and inbound sides. In the getting started page (linked above) they suggest this:

Outbound

SocialAuthManager manager = new SocialAuthManager();
String successUrl = "http://my.domain.com/socialauthd/successAction.xhtml";
String url = manager.getAuthenticationUrl(id, successUrl);
// Store in session
session.setAttribute("authManager", manager);

Inbound

// get the auth provider manager from session
SocialAuthManager manager = (SocialAuthManager)session.getAttribute("authManager");

The problem I have is that I don't see how this can work, and it doesn't in testing. They suggest storing a reference to an instance of SocialAuthManager in the session, however when the request is received from google a new session is created. It doesn't have the JSESSIONID cookie and so isn't part of the session that sent the request to google in the first place.

To work around this I got a unique per-request id from the socialauth api (openid.assoc_handle - it's sent as a query param), put it in a concurrentHashMap in an app scoped bean, and retrieve the reference in a preRenderView listener in the completion page (successUrl - badly named in the example as it is called either way).

This all seems like a lot of hassle for something that isn't included in the documentation. I've tried this with @RequestScoped CDI beans, although I usually use CODI @ViewAccessScoped. With CODI I've tried adding the windowId to the success URL, and also adding the JSESSIONID cookie to the redirect, but neither approaches work. I don't think the bean scope is relevant but the more information the better.

I could dive into the spring, seam and struts examples but for a pure EE 6 developer it's a lot of overhead, and with a better understanding of this issue I can produce a simple, working, JSF only example which I will make available to the socialauth team for use on google code.

Am I missing something obvious or does this just have to be complicated? and if so why did they document an approach that simply doesn't work?

Edit: I think that the successUrl may be named more appropriately than I thought, because in testing with Yahoo I realise that you won't be redirected back to your own site unless correct login details are provided. I expect this is the same for all providers. I have added some comments regarding this solution to the socialauth site, and also to an issue I logged about this problem (neither of which have received any response from anyone involved in the socialauth project).

Answer 1

Include the jsessionid path parameter in the callback URL.

String successUrl = "http://my.domain.com/socialauthd/successAction.xhtml"
    + ";jsessionid=" + session.getId();

Note that this is not specific to JSF API, but to Servlet API (chapter 7.1.3, URL rewriting).