locked
SignalR 2.0.3 vs 2.0.2 - Context.User is no longer taking on value applied to HttpContextBase.User during AuthorizeHubConnection RRS feed

  • Question

  • User1761027650 posted

    Hi gang,

    I'm trying to upgrade from SignalR 2.0.2 to 2.0.3 to take advantage of the "death spiral" fix.  With 2.0.3, I'm hitting a change in behavior w.r.t. HubCallerContext.User.

    Some background:

    We've created a custom authorize attribute based on IAuthorizeHubConnection and IAuthorizeHubMethodInvocation..  here it is below:

        [AttributeUsage(AttributeTargets.Class, Inherited = false, AllowMultiple = false)]
        public class OurCustomAuthorizeAttribute : Attribute, IAuthorizeHubConnection, IAuthorizeHubMethodInvocation
        {
            public bool RequireSsl { get; set; }
    
            public bool AuthorizeHubMethodInvocation(IHubIncomingInvokerContext hubIncomingInvokerContext, bool appliesToMethod)
            {
                return true;
            }
    
            public bool AuthorizeHubConnection(HubDescriptor hubDescriptor, IRequest request)
            {
                bool result;
    
                try
                {
                    var context = request.GetHttpContext();
    
                    using (context.NewScope())		// Extension method that sets up a DB access context so we can access the user repository
                    {
                        result = context.Authenticate();	// Extension method that (if successful) creates a custom principal and assigns it to context.User
                    }
                }
                catch
                {
                    result = false;
                }
    
                return result;
            }
        }
    

    In 2.0.2, when my hub methods are called, the HubCallerContext.User property is the custom principal that was initialized and assigned within the AuthorizeHubConnection(..) method invocation.

    In 2.0.3, when the hub method is called, HubCallerContext.User has reverted to the generic principal (i.e. not the one set up within AuthorizeHubConnection).

    Is this a bug introduced in 2.0.3?  If it's actually a "feature", then what is the "right" way to initialize a custom principal once for the connection, then have it available on client hub method invocations?

    Thanks for your help,

    Tyler

    Tuesday, May 13, 2014 2:50 PM

All replies

  • User298290605 posted

    That could be a bug. We fixed an issue regarding Context.User in 2.0.3 but it's possible you may have uncovered a regression.

    Would you mind creating an issue at https://github.com/signalr/signalr/issues please and provide a simple repro app we can use to see the problem?

    Tuesday, May 13, 2014 5:27 PM
  • User1761027650 posted

    Hi Damian,

    I've worked out a braindead simple repro and raised a bug over on github  (https://github.com/SignalR/SignalR/issues/3034).

    Thanks for the quick response!   Let me know if I'm doing something strange, or if there's anything else I can do to help.  In the meantime, I'm noodling on a workaround for the short-term.

    Tyler

    Tuesday, May 13, 2014 9:40 PM
  • User1761027650 posted

    Hi Damian,

    Just a quick check-in to see if you were able to reproduce the bug using the sample code I'd included in the bug report I raised over here:

    https://github.com/SignalR/SignalR/issues/3034

    Did I raise the bug in the right spot? anything else you need? 

    Also, I've tried a workaround that boils down to:

    1. within the attribute's AuthorizeHubMethodInvocation implementation, store some context in a caller context variable:  

          hubIncomingInvokerContext.Hub.Clients.Caller.userIdContext = someFairlySmallThing;
    2. within the hub method, access the caller context variable:

          var someFairlySmallThing = Clients.Caller.userIdContext;

    This has been sort of working, but it looks like there are edge cases where the hub method for a given client is not always receiving my custom userIdContext variable?  I'm still digging, but wanted to run that by you to see if there are red flags?

    Thanks,

    Tyler

    Tuesday, May 20, 2014 3:00 PM