Unable to login with fresh IIS installation for 4.5.1

I have…

  • [ X] Checked the logs and have provided the logs if I found something suspicious there

I’m submitting a…

  • [ ] Regression (a behavior that stopped working in a new release)
  • [X ] Bug report
  • [ ] Performance issue
  • [ ] Documentation issue or request

Current behavior

I navigate to the local Squidex URL and click on “Login to Squidex”. A pop up is displayed, where I enter the initial credentials as this is the first time to login.

The login window doesn’t go away

Expected behavior

Once the creditentials are provided, I should be able to log in to the system

Minimal reproduction of the problem

Follow the instructions provided in the IIS installation guide

Set the appSettings.Production.json to the following

appSettings production configuration

“urls”: {
* The url where your squidex installation is available at.
“baseUrl”: “http://localhost:8081
“identity”: {

* Disable authentication with google, github and microsoft login.
“googleClient”: “”,
“googleSecret”: “”,
“githubClient”: “”,
“githubSecret”: “”,
“microsoftClient”: “”,
“microsoftSecret”: “”,

* Initial username and password.
“adminEmail”: "admin@squidex.io",
“adminPassword”: “save1q2w3e$R”,
“assetStore”: {
“folder”: {

* Define where to store the assets.
“path”: “C:\Squidex_4_5_1\assets”
“orleans”: {

* Disable clustering!
“clustering”: “Development”


  • [ ] Self hosted with docker
  • [X] Self hosted with other version
  • [ ] Cloud version

Version: [4.5.1]


  • [X] Chrome (desktop)
  • [ ] Chrome (Android)
  • [ ] Chrome (iOS)
  • [ ] Firefox
  • [ ] Safari (desktop)
  • [ ] Safari (iOS)
  • [ ] IE
  • [ ] Edge


  • In Mongo DB, the admin user is created with the following details
Identity_Users Document


  • In the log file, there is the following error:
TokenDeserializeException in log file


“logLevel”: “Error”,

“message”: “An exception was thrown while deserializing the token.”,

“eventId”: {

"id": 7,

"name": "TokenDeserializeException"


“app”: {

"name": "Squidex",

"version": "",

"sessionId": "c80d3025-04fc-4de1-ba60-6540892137b7"


“web”: {

"requestId": "|bbbd417d-4dbff54f9ef47b1d.",

"requestPath": "/Account/Login",

"requestMethod": "GET",

"routeValues": {

  "area": "IdentityServer",

  "action": "Login",

  "controller": "Account"



“timestamp”: “2020-08-17T20:39:52Z”,

“category”: “Microsoft.AspNetCore.Antiforgery.DefaultAntiforgery”,

“exception”: {

"type": "Microsoft.AspNetCore.Antiforgery.AntiforgeryValidationException",

"message": "The antiforgery token could not be decrypted.",

"stackTrace": "   at Microsoft.AspNetCore.Antiforgery.DefaultAntiforgeryTokenSerializer.Deserialize(String serializedToken)\r\n   at Microsoft.AspNetCore.Antiforgery.DefaultAntiforgery.GetCookieTokenDoesNotThrow(HttpContext httpContext)"



  • In the log file, it is indicated that it is a production environment
Hosting environment log


“logLevel”: “Information”,

“message”: “Hosting environment: Production”,

“envName”: “Production”,

“app”: {

"name": "Squidex",

"version": "",

"sessionId": "c80d3025-04fc-4de1-ba60-6540892137b7"


“timestamp”: “2020-08-17T20:23:20Z”,

“category”: “Microsoft.Hosting.Lifetime”


  • In the log file, there are the typical Identity call back traces (I can add the details, if needed)

To be honest, I have no idea what this is, I do not use IIS myself and do not test it regularly on IIS. I have to install it myself and just test it out.

Thank you for your prompt response Sebastian. I appreciate that you will try it out at your end. In the meantime, I will try it again with freshly downloaded binaries and let you know, if something changes. Thanks.

Are you running with https? I was not able to get it working without https.

But it works with firefox and http. It seems that Chrome just does not sets the cookie.

I was running it with http as it was a local machine.

I can confirm that it runs with firefox and http as well as with Chrome and https. I think this Chrome issue might be related to a recent Chrome update as it used to work before on different system.

Thank you again for your help!

1 Like

In general http is not recommended anymore. There is a very nice IIS integration for lets encrypt that I have used before. No good excuse anymore to use http :wink: