/feat | Ability to Login to SOGo with a One-Click-Link from another Application

[xLixon]

Contribution Guidelines

• I've read the contribution guidelines and wholeheartedly agree them

What does this PR include?

Short Description

This PR is a little "Add-On" to the SOGo-One-Click-Auth already implemented in Mailcow.
It gives the function to create a token for an Login to SOGo From other applications only with the API token.

How does it work?

1. POST Request from Application to Mailcow
   -> Body: username: {MAILBOX EMAIL ADDRESS} | apikey: {APIKEY} (JSON)
2. Response:
   -> Body: success: true/false | username: {RETURN OF USERNAME} | token: {ONE-TIME AUTH TOKEN FOR SOGO}
3. User gets redirected to /sogossologin/sogo-auth.php?email=EMAIL&token=TOKEN
   -> GET Parameters: email: {MAILBOX EMAIL ADDRESS} | token: {ONE-TIME AUTH TOKEN}

Tadaaa! User is logged in to SOGo.

---

Yes, that means that with the API Key, everyone can login to a Mailaccount. But Admins can login from the panel either way.
And there is no difference between a comprimized Admin Mailcow Account or a leaked API-Key because the API Key can do as much as the admin account.

Affected Containers

• php-fpm
• sogo

Did you run tests?

What did you tested?

I generated a token, used the token in the URL and got logged in to SOGo

What were the final results? (Awaited, got)

Everything worked just as i intended it to.

[milkmaker]

Thanks for contributing!

I noticed that you didn't select staging as your base branch. Please change the base branch to staging.
See the attached picture on how to change the base branch to staging:

[DerLinkman]

Your branch is not based on your staging branch...

Also: affected containers are not filled out!

Please read the contribution guidelines to fulfill our requirements for a pr...

[xLixon]

I filled the affected containers:
"No containers affected."
If the staging branch is "needed", i will soon push another version with the staging branch

[DerLinkman]

But no containers affected is not right.

Affected are:

• php-fpm
• sogo (at least at some part)

[xLixon]

But are they affected even tho i didnt even change anything in the containers?

[DerLinkman]

You made changes to use the both containers. PHP to parse this script and sogo to authenticate with, so yes.

Why do we discuss about this? Simply add this and i'm fine.

[xLixon]

Okey if this are changes then i will add it.
I didnt mean to discuss this, i just wanted to understand what is a "change". I thought changes are only things i activly changed in the container but it seems like only using them is also a change. thanks for this info!

[FreddleSpl0it]

It would be better if there were an SSO for users to log in to the mailcow UI, similar to the existing Domain Admin SSO feature. From there, the user could navigate further to webmail or be directly redirected to SOGo, leveraging the existing sogo-auth.php script. I'm suggesting this because, with the OIDC and LDAP features, direct login to SOGo won't be possible, everything needs to go through mailcow's PHP sessions.

I believe there's already a branch with this feature, but it hasn't been merged yet.
eb33166

[xLixon]

Can you maybe explain this a little further?Because i think that is already like you said.The Login is already processed by mailcow and also saved with the data mailcow is using for their own "Direct-Login"-Method

[FreddleSpl0it]

Can you maybe explain this a little further?Because i think that is already like you said.The Login is already processed by mailcow and also saved with the data mailcow is using for their own "Direct-Login"-MethodVon meinem/meiner Galaxy gesendet-------- Ursprüngliche Nachricht --------Von: FreddleSpl0it @.> Datum: 08.11.24 07:52 (GMT+01:00) An: mailcow/mailcow-dockerized @.> Cc: xLixon @.>, Author @.> Betreff: Re: [mailcow/mailcow-dockerized] /feat | Ability to Login to SOGo with a One-Click-Link from another Application (PR #6070) It would be better if there were an SSO for users to log in to the mailcow UI, similar to the existing Domain Admin SSO feature. From there, the user could navigate further to webmail or be directly redirected to SOGo, leveraging the existing sogo-auth.php script. I'm suggesting this because, with the OIDC and LDAP features, direct login to SOGo won't be possible, everything needs to go through mailcow's PHP sessions —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: @.***>

ah yes you are right, my bad.

[xLixon]

Can you maybe explain this a little further?Because i think that is already like you said.The Login is already processed by mailcow and also saved with the data mailcow is using for their own "Direct-Login"-MethodVon meinem/meiner Galaxy gesendet-------- Ursprüngliche Nachricht --------Von: FreddleSpl0it @.> Datum: 08.11.24 07:52 (GMT+01:00) An: mailcow/mailcow-dockerized _@**._> Cc: xLixon _@.>, Author @._> Betreff: Re: [mailcow/mailcow-dockerized] /feat | Ability to Login to SOGo with a One-Click-Link from another Application (PR #6070) It would be better if there were an SSO for users to log in to the mailcow UI, similar to the existing Domain Admin SSO feature. From there, the user could navigate further to webmail or be directly redirected to SOGo, leveraging the existing sogo-auth.php script. I'm suggesting this because, with the OIDC and LDAP features, direct login to SOGo won't be possible, everything needs to go through mailcow's PHP sessions —Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you authored the thread.Message ID: _@_.*>

ah yes you are right, my bad.

Did you try it?