locked
blazor server | IIS terminates the thread when using httpcontextaccesor.HttpContext.Connection.RemoteIpAddress RRS feed

  • Question

  • User2110873642 posted

    when debugging, the file '_blahblah.txt' appears on disk. - it works fine.

            httpContextAccessor.HttpContext.Connection.RemoteIpAddress.ToString();
            System.IO.File.WriteAllText(Environment.CurrentDirectory + @"\_blahblah.txt", "");

    when running on IIS, the file '_blahblah.txt' does not appear on the disk.

    it means that IIS does not process :

    httpContextAccessor.HttpContext.Connection.RemoteIpAddress.ToString();

    and terminates the thread.

    it seems to do more damage than this as well. i suspect that the entire app hangs from there and does no longer respond to any user.

    what can i do about it?

    Friday, August 14, 2020 12:26 AM

All replies

  • User-821857111 posted

    First thing to check is that the user account that the app is executing under (usually IISAPPPOOL/[ApplicatonPoolName]) has WRITE permissions to the specified directory.

    Friday, August 14, 2020 5:37 AM
  • User2110873642 posted

    no if i write the file to disk before using httpcontextaccesor, the file can be found on disk.

    Friday, August 14, 2020 1:39 PM
  • User2110873642 posted

    i found a log in event viewer:

    Category: Microsoft.AspNetCore.Components.Server.Circuits.CircuitHost EventId: 210 RequestId: 80000026-0001-fc00-b63f-84710c7967bb RequestPath: /_blazor SpanId: |e1d26cb8-4fa1ae41ab59608d. TraceId: e1d26cb8-4fa1ae41ab59608d ParentId: TransportConnectionId: -7T9CLfym_tCkY4Ik4dUSA Location change to 'http://lab.fazi.li/Gallery/Art%20of%20naming' in circuit 'GyWBNHHcujGrddBCu5Ifpwn3D8WlZopwwc_Ro8XLVdo' failed. Exception: Microsoft.AspNetCore.Components.LocationChangeException: An exception occurred while dispatching a location changed event. ---> System.NullReferenceException: Object reference not set to an instance of an object. at Fazili.Logging.Components.Recorder.LocationChanged(Object sender, LocationChangedEventArgs e) in C:\Users\fazio\source\repos\RiKoNET\Fazili.Logging\Components\Recorder.razor:line 20 at Microsoft.AspNetCore.Components.NavigationManager.NotifyLocationChanged(Boolean isInterceptedLink) --- End of inner exception stack trace --- at Microsoft.AspNetCore.Components.NavigationManager.NotifyLocationChanged(Boolean isInterceptedLink) at Microsoft.AspNetCore.Components.Server.Circuits.RemoteNavigationManager.NotifyLocationChanged(String uri, Boolean intercepted) at Microsoft.AspNetCore.Components.Server.Circuits.CircuitHost.<>c__DisplayClass45_0.<OnLocationChangedAsync>b__0() at Microsoft.AspNetCore.Components.Rendering.RendererSynchronizationContext.<>c.<InvokeAsync>b__8_0(Object state) --- End of stack trace from previous location where exception was thrown --- at Microsoft.AspNetCore.Components.Server.Circuits.CircuitHost.OnLocationChangedAsync(String uri, Boolean intercepted)
    Friday, August 14, 2020 1:51 PM
  • User2110873642 posted

    since the log points at 'line 20'. here is the testcode ive used:

    @inject Microsoft.AspNetCore.Http.IHttpContextAccessor httpContextAccessor
    @inject NavigationManager NavigationManager
    @implements IDisposable
    
    @code{
    
        protected override void OnInitialized()
        {
            // Subscribe to the event
            NavigationManager.LocationChanged += LocationChanged;
            base.OnInitialized();
        }
        void LocationChanged(object sender, Microsoft.AspNetCore.Components.Routing.LocationChangedEventArgs e)
        {
            //string navigationMethod = e.IsNavigationIntercepted ? "HTML" : "code";
            //System.Diagnostics.Debug.WriteLine($"Notified of navigation via {navigationMethod} to {e.Location}");
            System.IO.File.WriteAllText(Environment.CurrentDirectory + @"\_05.txt", "");
            string dummy = NavigationManager.Uri;

    //The following file was written to disk: prooves that the method was functioning System.IO.File.WriteAllText(Environment.CurrentDirectory + @"\_0.txt", "");
    line 20: httpContextAccessor.HttpContext.Connection.RemoteIpAddress.ToString();
    //The thread exitted. the following lines do not get executed:

    //The following file was not written to disk, prooves that the thread crashed. System.IO.File.WriteAllText(Environment.CurrentDirectory + @"\_06.txt", "");
    Fazili.Logging.Api.LogPageView(httpContextAccessor.HttpContext.Connection.RemoteIpAddress.ToString(), NavigationManager.Uri); System.IO.File.WriteAllText(Environment.CurrentDirectory + @"\_1.txt", ""); } void IDisposable.Dispose() { // Unsubscribe from the event when our component is disposed NavigationManager.LocationChanged -= LocationChanged; } protected override void OnAfterRender(bool firstRender) { if (firstRender) { //Fazili.Logging.Api.LogPageView(httpContextAccessor.HttpContext.Connection.RemoteIpAddress.ToString(), NavigationManager.Uri); } } }

    Friday, August 14, 2020 2:04 PM
  • User2110873642 posted

    after the thread has crashed, the server is entirely destroyed. the browser keeps working, but the server does not render anything anymore until i restart the app.

    Friday, August 14, 2020 2:15 PM
  • User475983607 posted

    fazioliamboina

    after the thread has crashed, the server is entirely destroyed. the browser keeps working, but the server does not render anything anymore until i restart the app.

    I and the community have explained the problem with your design several times.  The HttpContext is available is when the Blazor application loads for the first time.   Not to be confused with loading a page.   After the first load, the context is null because Blazor is a client side application and runs in the browser.

    In a previous post I showed you how to get the IP address when the Blazor Server app first loads.  I clearly and openly explained that it is up to you to persist the IP address from that point on.   I also provided the links to the official docs that explain the same.   For some unknown reason, you continue to use the pattern incorrectly and blame Blazor.  

    Another way to get the IP address is making an HTTP request to a Web API endpoint.  This will allow you to get the IP on demand at any time and explained in a previous thread.  No matter how you decided to get the IP address, once you have the IP address use standard state management to to persist the IP. 

    Friday, August 14, 2020 2:45 PM
  • User-474980206 posted

    As there is no current request when the component is called via signal/r I assume the accessor throws an error. It may be valid on the server pre-render of a component. A crash kills the signal/r connection, and the current version of server blazor has no recovery for lost connection.

    Friday, August 14, 2020 2:51 PM
  • User2110873642 posted

    The HttpContext is available is when the Blazor application loads for the first time.

    i know, i just thought that the httpcontextaccesor took care of state management for me. i thought that it was remembered, because it worked while debugging.

    why does it work when debugging?

    Friday, August 14, 2020 3:54 PM
  • User2110873642 posted

    For some unknown reason, you continue to use the pattern incorrectly and blame Blazor.  

    true, i dont want to use the pattern corectly. and i will try whatever i can to hack blazor until it works how i want it to work. until i can finaly become productive.

    blazor makes life worse, it really does, because blazor forces me to take everthing out of class libraries and into the main project, because of the worst invention ever DI.

    how would you ever state-manage an user IP from a class library? you would need to hack DI.

    Friday, August 14, 2020 4:13 PM
  • User475983607 posted

    i know, i just thought that the httpcontextaccesor took care of state management for me. i thought that it was remembered, because it worked while debugging.

    No, the HttpContextAccessor accesses the current context.   

    why does it work when debugging?

    It's not working.  You made a false assumption probably due to an observation rather than a valid test.  

    Friday, August 14, 2020 4:21 PM
  • User2110873642 posted

    it really worked when debugging, i have extensively tested it. i got the ::1 ip adres, i logged every onlocationchanged, so it worked great. thats why i was so suprised it doesnt work on full IIS.

    Friday, August 14, 2020 9:14 PM
  • User475983607 posted

    it really worked when debugging, i have extensively tested it. i got the ::1 ip adres, i logged every onlocationchanged, so it worked great. thats why i was so suprised it doesnt work on full IIS.

    I'm sure you experienced behavior that seemed to work.  The reality is the http context is only available when the Blazor Server initially loads.  After Blazor application loads, everything is client side and web sockets. 

    Saturday, August 15, 2020 12:26 AM