User not signed in on consent page


#1

Hello :slight_smile:

At first I’d like to point out I’m very excited about Squidex and its potential to make our life a lot easier creating a website for our nonprofit organisation. Not to mention the life of the future content managers. :smiley:

After playing around in the Squidex Cloud, yesterday I tried to get a local instance of Squidex running.
My goal is to connect our own IdenityServer to Squidex and we came pretty far with it in a few hours time.

The problem I experience is the user being null at the time we try to submit the consent settings during the signup proces of a user. We are using the master branch (checked out about 24 hours before posting this), with unchanged code except for of course the configuration in appsettings.json to connect our OIDC client, which seems to work fine.

We can see the user gets logged in succesfully and gets redirected to the consent page, as you can see at this piece of code.

if (!isLoggedIn)
{
    return RedirectToAction(nameof(Login));
}
else if (user != null && !user.HasConsent())
{
--> return RedirectToAction(nameof(Consent), new { returnUrl }); <--
}
else
{
    return RedirectToReturnUrl(returnUrl);
}

But when we get there and submit the consent settings, the User (from HttpContext) is null
at this code line.

var user = await userManager.GetUserWithClaimsAsync(User);

The first thought was that we did something wrong in configuring our IdentityServer, but the result stays the same when logging in with a Google Account. Could you help with this?

The new user does show up in the MongoDb database, but when we try to log in at this stage, we just get redirected to the login page again and again.

My assumption is that there should be a cookie set after logging in, right? That way the consent page can use the cookie to see the just signed up user.

I hope you can help, we’re really looking forward to using Squidex as a provider of content for our organisations new website. Thank you for all the hard work put in to this project and thanks in advance for helping us out.

Kinds regards,
Tim


#2

Very strange. Have you changed something else? The code is exactly the same to the cloud in this area and I guess you got the consent screen there.


#3

Nope we did not change anything. Can it be a problem we’re running at localhost for both the IdentityServer and the Squidex instance? Of course we’re running it at different ports.

We run the project in IIS through a debug session in Visual Studio 2017.

To be exact, in appsettings.json we changed:

  • under ‘assetStore’, ‘folder’:
    • changed the path to a folder on the C drive, as we experienced some problems with folder permissions.
  • under ‘identity’:
    • “allowPasswordAuth” to false.
    • changed the gitHub and microsoft clients to an empty string, leaving the Google client intact.
    • changed the oidc settings to our own values.

#4

No, I don’t think that identity server is the problem. Have you tried to delete all cookies on the consent page?


#5

Yes I did. Also going through the process in an other browser or with the incognito feature doesn’t make a change unfortunately :frowning:


#6

I cannot believe I did not try this earlier, but the issue does not occur in Microsoft Edge! It does occurs in both Google Chrome and Mozilla Firefox.

Looking at the cookies when I’m on the consent page:

  • Chrome has only one cookie set:
    • .AspNetCore.Antiforgery.6gqB-tCosRY
  • Firefox has four:
    • .AspNetCore.Antiforgery.6gqB-tCosRY
    • .AspNetCore.Identity.Application
    • idsrv.session
    • {5fa6617d-7449-4e49-ac6d-13fbdb2afe24}
  • Edge has three:
    • .AspNetCore.Antiforgery.6gqB-tCosRY
    • .AspNetCore.Identity.Application
    • idsrv.session

Does this tell you something? I’m hoping for it, haha! :smiley:

I don’t know yet when I can proceed investigating the issue, but the first things I think of is disabling HTTPS at our IdentityServer (or enable it at Squidex). If that doesn’t work, maybe I should add some entries to my Windows hosts file, so not all applications use the localhost name.

To be continued! Thank you for the help thus far :slight_smile:


#7

I tried it again, but I cannot reproduce it. Can you debug through it and chech the User property?