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?


#8

Hi Sebastian,

I’m sorry for my late response! Finally I found some time to debug through it again. I took some screenshots of the process.

The externalLogin is set and I can see my email address at the “ProviderDisplayName”.

This far every step succeeds. Here we can see there’s a bunch of claims, but there are no ‘urn:squidex’ claims (yet?). Is that alright? Also we can see the first user is given the Admin permissions.

Now this is where it goes wrong. At the consent page, we lost all claims.
I see I did not point this out correctly earlier: the User property is not null, but it has no claims anymore.
The ‘user’ variable will be null, as the ‘GetUserWithClaimsAsync’ method cannot locate the user in the database, as the principal does not have any information to identity the user. The Gmail login provider has the same result as our own Identity Server login provider.

Hope this helps! Thanks for your time and your patience. I’ll try to respond quicker next time :slight_smile:

Kind regards,
Tim


#9

Thank you. The easiest solution would be if you could provide me your identity server or access to it, so that I can debug it myself.


#10

Btw: Do you have a proxy or something in your company that could affect the result?


#11

I’ve no proxy or anything network related set up for our company on my device.

Unfortunately I cannot provide you with our IdentityServer solution, but I’m planning to set up a testing environment. When that is set up, I can provide you access to it. Though the issue also occurs when using Google as a login provider.


#12

But something must be different on your side. It does not happen in the cloud version. It does not happen on my local machine and it does not happen for other customers / users.

So we have to find out where this difference is. Where are you hosting it? Docker? Just local Kestrel? IIS? IIS Express?


#13

I agree! I tried running the Squidex project in Kerstel and IIS Express, started by a debug session in VS 2017. I also tried just the ‘dotnet run’ command.

Is there any additional configuration I should mention when running the project in a debug session in Visual Studio 2017?


#14

I use the same setting.


#15

This is my user in the consent screen:

Just started Squidex from VS with empty DB and default settings.


#16

Hi, I finally found the issue.

The problem are the cookies and how they work:

For historical reasons, cookies contain a number of security and privacy infelicities. For example, a server can indicate that a given cookie is intended for “secure” connections, but the Secure attribute does not provide integrity in the presence of an active network attacker. Similarly, cookies for a given host are shared across all the ports on that host, even though the usual “same-origin policy” used by web browsers isolates content retrieved via different ports.

Because identity server and squidex use the same tech stack they also use the same keys for cookies. And both add the cookie for the authenticated user. So the flow is like this:

  1. You click login in Squidex
  2. Squidex redirects to identity server.
  3. You login in identity server.
  4. Identity server adds the cookie.
  5. Squidex adds the same cookie to the /identity-server path.
  6. Squidex takes the wrong cookie in consent page and fails to unencrypt it, because it is encrypted from another process.

The solution is to use different host names or to tell identity server to use another cookie name, e.g. I use the following cookie name in Squidex-Identity now:

services.ConfigureApplicationCookie(options =>
{
    options.Cookie.Name = ".sq.id.auth";
});

The current master branch of Squidex also uses a custom cookie name.


#17

Hi Sebastian,

That’s great news! I just tried to check out the latest version from the master branch and it worked right away. Thank you very much for diving into this :slight_smile:

Maybe it’s not related to this forum thread, but I’d like to point out what now see in my browser dev tools after logging in:

On this screenshot you can see these Api requests are being send over and over again. This does not only occur when logging in for the first time. Also a Google login has the same result.

Thank you very much for finding and solving the issue with the cookies! I’m very excited to set up my first project with Squidex soon.

Kind regards,
Tim


#18

Is it an infinite loop?


#19

Yes, that’s correct!


#20

Mhm, okay…did not happen in my case, I will have another look.