First OAuth authentication forwards to Mailcow backend instead of target URL

mkrecek234 commented 1 week ago

Contribution guidelines

[X] I've read the contribution guidelines and wholeheartedly agree

I've found a bug and checked that ...

[X] ... I understand that not following the below instructions will result in immediate closure and/or deletion of my issue.
[X] ... I have understood that this bug report is dedicated for bugs, and not for support-related inquiries.
[X] ... I have understood that answers are voluntary and community-driven, and not commercial support.
[X] ... I have verified that my issue has not been already answered in the past. I also checked previous issues.

Description

I am using NExtcloud Social Login with Mailcow as an OAuth provider for long time now - with the most recent updates (Social Login - but also Mailcow, not sure what caused it), I run into the following issue:

If am not logged into another Mailcow app, and login into Nextcloud using OAuth, I am correctly passed to the Mailcow OAuth login screen
- Enter username and password correctly
- Instead of then seeing the Mailcow screen to "Authorize application" (as before), it logs me into the Mailcow interface

Expected behaviour: do not show Mailcow web interface, but "Authorize application screen"

Now that I am authenticated in Mailcow, if I then try again to log into Nextcloud using mailcow, it jumps right away to the "authorize application" screen correctly. (I don't have to enter username/password, as I am logged in already).

Logs:

Not sure which logs are helpful, please instruct

Steps to reproduce:

see above

Which branch are you using?

master

Which architecture are you using?

x86

Operating System:

Ubuntu 22.04

Server/VM specifications:

16GB, 4 cores

Is Apparmor, SELinux or similar active?

no

Virtualization technology:

not sure

Docker version:

not sure

docker-compose version or docker compose version:

not sure

mailcow version:

most recent official

Reverse proxy:

Apache2

Logs of git diff:

N/A

Logs of iptables -L -vn:

N/A

Logs of ip6tables -L -vn:

N/A

Logs of iptables -L -vn -t nat:

N/A

Logs of ip6tables -L -vn -t nat:

N/A

DNS check:

N/A

beerlao commented 1 week ago

I can't confirm, I'm using the same setup and it works like a charm as before.

ashkov commented 6 days ago

Confirm

DerLinkman commented 6 days ago

Actually, i don't think this is a mailcow problem as we did not changed anything here which is live in the master branch which could explain this, as the changes regarding OIDC/LDAP are not live yet.

I would speculate it is a change from nextcloud which is causing this thing to stopped working... can someone confirm that?

heavygale commented 6 days ago

I'm having the same issue. Thanks for the workaround: Try it again (without logging out of mailcow) to continue the OAuth2 login process.

I rather suspect a bug in mailcow, because nextcloud correctly redirects to the mailcow authorize login mask. If you log in there, however, you end up in the mailcow interface instead of in the ‘authorise application’ dialogue. I don't see how an OAuth2 application should trigger such behaviour. Either mailcow recognises that you want to do OAuth2 login and shows the corresponding login mask (which it does) or not (i.e. regular login mask). Before mailcow redirects back to nextcloud, nextcloud should have no influence on the login process within mailcow. If you start the process again after logging in to mailcow, you will land directly in the ‘authorise application’ dialogue and if you confirm this, you will correctly be retourned to nextcloud (with successful login to nextcloud via OAuth2).

mkrecek234 commented 6 days ago

@DerLinkman I tend to agree that it is on the Nextcloud Social Login app. I had opened an issue there https://github.com/zorn-v/nextcloud-social-login/issues/489 as well. It can well be on their side if forward URLs are not properly transmitted to mailcow OAuth provider. @heavygale @ashkov Please comment on the Nextcloud Social Login GitHub issue as well, so far no activity there on my posted issue. Thanks all for your reactions. I will make sure to close this issue when we see it is a Nextcloud topic.

heavygale commented 6 days ago

But how could the login succeed on retry (when already logged in to mailcow), if nextcloud doesn't provide the correct URLs? And if there's a parameter missing in the call, shoudn't mailcow display a corresponding error message?

ashkov commented 4 days ago

I'm experiencing this without nextcloud, in custom integration with django_allauth module. I'm as a developer of custom OAuth integration, don't understand, what I should do to make mailcow redirect to permissions page after login to mailcow admin?

It seem that I send authorize request as usual do in any other OAuth apps.

beerlao commented 4 days ago

Strange. I am using Nextcloud (30.0.2) as well as Authentik with oauth and both are working with no issues whatsoever with mailcow's latest release as IDP.

WhoAmI0501 commented 1 day ago

Hello, we are facing the same issue with Mailcow as OAuth2 IDP for GitLab, Grafana, Rocket.Chat and Nextcloud.

After a deeper investigation, we didnt find any bug or solution within the mentioned apps, so we also assume a bug in mailcow.

After logging in via OAuth2, Mailcow returns a 302 Found with a Location Response header to /user.

WhoAmI0501 commented 1 day ago

@DerLinkman So the actual, problematic redirect happens here: https://github.com/mailcow/mailcow-dockerized/blob/master/data/web/inc/triggers.inc.php#L114

Actually this line was changed in 2018 for the last time, so i guess there is no relation. The line after that was changed in august this year for the last time in this commit, which looks more conspicuous to me. But i am not sure, whether this is the exact reason why this happens.

heavygale commented 1 day ago

Indeed, removing the new "die();" line restores the previous behavior and the user is correctly redirected to /oauth/authorize again. So this redirect must override the redirect to /user at a later point? I can't find where this is done.

WhoAmI0501 commented 1 day ago

Indeed, removing the new "die();" line restores the previous behavior and the user is correctly redirected to /oauth/authorize again.

I can reproduce this. But i am unsure, which side effects will happen, if this die() statement will be removed permanently. I assume, that it wasnt placed without a reason at this point. May you can tell us more about this change, @FreddleSpl0it?

WhoAmI0501 commented 1 day ago

So this redirect must override the redirect to /user at a later point? I can't find where this is done.

Actually not, because you are not directly redirected to the service provider (e.g. Nextcloud, GitLab, ...). Mailcow will show you the authorize page first, so actually the mentioned override must remove(?) the Location header again. I also dont really get, what happening there.

heavygale commented 1 day ago

Yes, i meant the mailcow internal redirect from the login page to the authorize page (/oauth/authorize[...]), instead of /user.

mailcow / mailcow-dockerized