Quickly found the problem... MVC Functions are executed inside its own HttpContext, which is a copy of the main content which you can see here https://github.com/Orckestra/C1-Packages/blob/master/Composite.AspNet.MvcFunctions/Composite.AspNet.MvcFunctions/FunctionProvider/MvcFunctionBase.cs#L171.
And while they pretend to copy all the data from the Parent to the Child context, as you can see here https://github.com/Orckestra/C1-Packages/blob/master/Composite.AspNet.MvcFunctions/Composite.AspNet.MvcFunctions/FunctionProvider/MvcFunctionBase.cs#L156, they are not very good at it. IMO ie. ALL Items should be copied, which would have copied the OwinContext as well.
A quick fix for you is to resolve OwinContext on HttpContext.Current, instead of the HttpContext properties on Controller like this
And while they pretend to copy all the data from the Parent to the Child context, as you can see here https://github.com/Orckestra/C1-Packages/blob/master/Composite.AspNet.MvcFunctions/Composite.AspNet.MvcFunctions/FunctionProvider/MvcFunctionBase.cs#L156, they are not very good at it. IMO ie. ALL Items should be copied, which would have copied the OwinContext as well.
A quick fix for you is to resolve OwinContext on HttpContext.Current, instead of the HttpContext properties on Controller like this
protected IOwinContext OwinContext
{
get { return System.Web.HttpContext.Current.GetOwinContext(); }
}
And then you can get your managers like this
public ApplicationSignInManager SignInManager
{
get { return _signInManager ?? OwinContext.Get<ApplicationSignInManager>(); }
private set { _signInManager = value; }
}
public ApplicationUserManager UserManager
{
get { return _userManager ?? OwinContext.GetUserManager<ApplicationUserManager>(); }
private set { _userManager = value; }
}