Open Closed

Azure and Microsoft Authentication intermittently breaking logins #565


User avatar
0
michael.sudnik created
  • ABP Framework version: v3.3.1
  • UI type: MVC
  • Tiered (MVC) or Identity Server Seperated (Angular): MVC
  • Exception message and stack trace:
  • Steps to reproduce the issue:

Hi,

I have spent more than a day working through this problem and can reproduce the problem reliably using an unmodified solution created using the abp suite.

With the Microsoft external provider enabled, the Log In button will sometimes timeout (after 230 seconds, as defined by azure app services with no response). It normally happens the 3rd or 4th time after clicking log out and logging back in again. I have seen it freeze in both ways, when using a username and password or when using the now enabled microsoft login. It just times out after an arbitrary number of attempts.

  1. Create new solution using abp suite (application, MVC, no mobile, mongodb, not tiered, not preview)
  2. Publish it to a new azure app service
  3. Access the website through the ...azurewebsites.net url
  4. Enable the Microsoft external provider within the account settings UI
  5. Log out, Log in, Log out, log in, ... a few more times maybe... then timeout on loggin in

This only appears to be a problem with running within azure. I do not have the same problem when running locally.

I am using MongoDB Atlas, but do not see anything in the logs to indicate a problem with this communication. I event extended the MongoDB code to ensure that the Client was created with logging capabilities (it would be useful to have a way to create a MongoDB Client through a factory somewhere) and did not see any problems

I have enabled every log that I know how to, and do not see anything after the post request is started to be handled. This led me to add my own middleware to try and capture more information to verify that there were no problems with the request. By doing this, I managed to find a "hack" which appears to work as a temporary fix and may help to identify the real cause. I am not sure if the hack works as a result of it forcing the request body to be read before moving on to the next request delegate, or if it works because of the minor additional time that this middleware is taking. I tried just explicitly adding an "await Task.Delay(50)", but this did not fix the problem. I am unable to dig any deeper and at the limit of my knowledge.

public class RequestResponseLoggingMiddleware
    {
        private readonly RequestDelegate _next;

        public RequestResponseLoggingMiddleware(RequestDelegate next)
        {
            _next = next;
        }

        public async Task Invoke(HttpContext httpContext)
        {
            if (httpContext == null)
                throw new ArgumentNullException(nameof(httpContext));

            httpContext.Request.EnableBuffering();
            Stream body = httpContext.Request.Body;
            body.Seek(0, SeekOrigin.Begin);
            byte[] buffer = new byte[Convert.ToInt32(httpContext.Request.ContentLength)];
            await body.ReadAsync(buffer, 0, buffer.Length);
            body.Seek(0, SeekOrigin.Begin);
            httpContext.Request.Body = body;

            await _next(httpContext);
        }
    }

3 Answer(s)
  • User Avatar
    0
    michael.sudnik created

    How do I get this escalated to the support team?

  • User Avatar
    0
    michael.sudnik created

    This appears to work without any problems now that I have upgraded to v4.0.0-rc3

  • User Avatar
    0
    alper created
    Support Team Director

    good to hear that.

Made with ❤️ on ABP v9.1.0-preview. Updated on November 11, 2024, 11:11