Activities of "URITECHNOLOGY"

This solution is not an angurlar version. We're using memory cache, no replacements have been done to this logic at all. It is however, load balanced on two iis servers, could that be causing an issue? I will make sure to email you the logs ASAP.

Thank you for the quick response!

It would be great to have some one from the support team comment on this to ensure that this is the fix before we deploy.

https://support.aspnetzero.com/QA/Questions/8783/Login-Loop---Chrome-Fails---IE-Working---Hosted-In-IIS

@marble68 Above is the fix.

           var cookieOptions = new CookiePolicyOptions
            {
                MinimumSameSitePolicy = SameSiteMode.None
            };
            app.UseCookiePolicy(cookieOptions);

If you apply the above code with and use a self-signed SSL cert for local development, it will work and impersonation will also work.

Internally it is calling the authentication controller using http which is breaking in chrome.

We manually set the cookie to https to bypass the strict, but its breaking the impersonation functionality because it is persisting through the session..

Below is what we are using to bypass the Strict policy set by Google Chrome

           var cookieOptions = new CookiePolicyOptions
            {
                MinimumSameSitePolicy = SameSiteMode.None
            };
            app.UseCookiePolicy(cookieOptions);

We need an example of how to set the cookie properly or figure out a configuration setting to redeploy the app using Chrome 80+.

All of our apps have been configured with HTTPS and strict secure.

This seems to be on a User profile basis. I can log on to another profile in windows and open chrome to complete auth.

We are seeing a 302 (redirect) response to /App so it is posting.

We have made zero changes to Authentication.

@marble68

We are using JQ 8.9. It is redirecting to %2fApp. We are not using MFA or two factor.

It is not logging all the way in, no .AspNetCore.Identity.Application Cookie is set.

Only when that file named "Local State" is regenerated will it complete the log in.

One of the objects in the file (hard to tell which one exactly) is probably persisting the session token from before the update.

In staging: Site is load balanced for 2 domains:

• wrmgincentives.uritechnology.com
• wrmgportal.uritechnology.com Both domains resolve to the same hosted folder on each server (A and B servers) All instances share the same database.

In Production: We have it deployed to two different servers for 2 different domains.

• wrmgincentives.com is load balanced
• wrmgportal.com is single server instance All instances share the same database.

How would this setup affect the site to produce multiple duplicate notifications?

thanks!

//tried this but generated up to 4 notifications, none of them returned a file
//_appNotifier.MarketingInvoiceGenerated(input.User, file.FileToken, file.FileType, file.FileName);

//current implementation
if (file != null)
            {
                _appNotifier.MarketingInvoiceGenerated(input.User, file.FileToken, file.FileType, file.FileName);
}
//tried this and it generates up to 3 notifications, some times the link works, sometimes not
//AsyncHelper.RunSync(async () => await _appNotifier.MarketingInvoiceGenerated(input.User, file.FileToken, file.FileType, file.FileName));

IN the appnotifier.cs page we have added: AppNotifier.cs

public async Task MarketingInvoiceGenerated(UserIdentifier argsUser, string fileToken, string fileType, string fileName)
        {
            var notificationData = new LocalizableMessageNotificationData(
                new LocalizableString(
                    "ClickToSeeMarketingInvoices",
                    PortalConsts.LocalizationSourceName
                )
            );

            notificationData["fileToken"] = fileToken;
            notificationData["fileType"] = fileType;
            notificationData["fileName"] = fileName;

            await _notificationPublisher.PublishAsync(AppNotificationNames.DownloadMarketingInvoices, notificationData, userIds: new[] { argsUser });
        }