[SOLVED] Problem with Login

Bugs Solved Bugs
1

I have…

  • [ ] Checked the logs and have uploaded a log file and provided a link because I found something suspicious there. Please do not post the log file in the topic because very often something important is missing.

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

Hi Sebastian, we are currently experiencing a bug with the login page (the bug is not always present).
We noted that after we login with the “popup” the container goes blank and stalls, we have to actually close the popup window and retry to login. We verified this problem with versions 7.3-7.5. Version 6.5 does not present this problem.
In order to verify this we have installed a test environment; the initial warning in the debugger was this:

Cookie “.AspNetCore.Antiforgery.6gqB-tCosRY” with the “SameSite” attribute value “Lax” or “Strict” was omitted because of a cross-site redirect.
and after the login popup after trying to login presents with this warning:
Cookie “INGRESSCOOKIE” does not have a proper “SameSite” attribute value. Soon, cookies without the “SameSite” attribute or with an invalid value will be treated as “Lax”. This means that the cookie will no longer be sent in third-party contexts. If your application depends on this cookie being available in such contexts, please add the “SameSite=None“ attribute to it. To know more about the “SameSite“ attribute, read https://developer.mozilla.org/docs/Web/HTTP/Headers/Set-Cookie/SameSite

Expected behavior

Popup window closes and executes the login.

Minimal reproduction of the problem

We have tried both in anonymous and normal versions of browser windows.
If you are not able to reproduce the problem with chrome, I noted that after logging in and then logging out try to log back in and that reproduces an error 400.

Environment

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

Version: 7.3, 7.4, 7.5

Browser:

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

Others:

2

Do you have an ingress running? Or something that could alternate the cookies?

3

Yes there is an ingress running, I have been told that the version 6.5 runs on the same stack and doesn’t exhibit the same problem.

4

I can reproduce it and will provide a fix today. It only happens with username and password authentication. Therefore it has not been recognized yet.

1 Like
5

Great news Sebastian,
thank you very much.

6

Hi Sebastian, Is there any news on the the fix?

7

Can you try docker tag dev-7546?

8

Hi Sebastian,
we managed to incorporate tag dev-7546 and seems to have resolved the login problem, BUT we have also noticed that the patch seems to have created other chaos within Squidex.

  • One of the first things we noticed was that after upgrading the rules that we had implemented disappeared.
  • Trying to change the workflow which we hadn’t touched in a while were no longer modifiable instead on saving the workflow gave us an error: (Failed to make the update. Another user has made a change. Please reload.)
  • Roles were no longer editable

After noticing these bugs we tried a rollback to the previous version but the problems above persisted.
If you have any ideas?

Lannie

9

I have not touched anything that has anything to do with that. I am not sure if it is related.

10

This topic was automatically closed after 2 days. New replies are no longer allowed.