Before I raise a bug report, I wanted to sanity check that I'm doing things
right.

I have code that looks (very) roughly like this:

public static Resut login(final String user, String password) {
  final Http.Context ctx = ctx();
  return async(WS.url("https://myssoprovider.com/login?user=" + user +
"&password=" + password).map(
    new Function<WS.Response, Result>() {
      public Result apply(WS.Response response) {
        if (response.status == 200) {
          ctx.session().put("user", user);
          return ok();
        } else {
          return notFound();
        }
      }
    });
  }

My first attempt was to use ctx() from within the map function, this of
course just threw an exception because the context is not set in the thread
local for the thread that handles the response.  But it seems not even
getting the context before the async part and then using that works, I can
put stuff in the session, but it seems no cookies get returned to the
client.  Is there another way to set session data in asynchronous requests?

If this is the pull request that Guillaume is referencing, then no, it
looks to me like it won't fix it:

https://github.com/playframework/Play20/pull/230

That pull request is only copying headers across.  I could be wrong, but it
looks to me like at that point, the session data is still just in a plain
map, and not encoded into a set cookie header in the response.  Anyway,
this has confirmed that it's a bug, so I'll raise an issue.  Hopefully it
can be fixed in a 2.0.x release.

Created here:

https://play.lighthouseapp.com/projects/82401-play-20/tickets/350-ses...

James, you're absolutely correct.
I've responded to your lighthouse ticket #350 with a solution to the problem.

Thanks for this Kevin, your patch solved the issue for me, although there
was a warning about unsafe operations in Result.java?

Is there any idea when this will be looked at and merged into master..? im
not sure what the timeline is for the 2.1 release or if there has already
been a cutoff?

Thanks

Ali

Hi Ali,

The warnings are actually from a different part of Results.java, and
were present even before my change.

I'm sorry, but I have no idea! I don't think there has been a cutoff
yet, and I would speculate that a 2.0.1 bugfix release is imminent.