[GH-ISSUE #974] Declarative config for multiple accounts

kerem commented

2026-02-25 21:35:15 +03:00

Owner

Originally created by @jonocodes on GitHub (Apr 22, 2024).
Original GitHub issue: https://github.com/cypht-org/cypht/issues/974

Originally assigned to: @Shadow243 on GitHub.

💬 Question

First off, thanks for this app. I'm very happy to have found it, as it fits the needs I am looking for on my new server.

I have about 10 IMAP accounts. I would like to set them up with a config file instead of using the UI. It looks like this can be done for only a single IMAP server via env var IMAP_AUTH_*.

Is there a recommended way to do this? Perhaps set it up once and use USER_CONFIG_TYPE=file
then copy that file to my new system?

Side note I am running this in NixOS which I only mention because declarative configs are the norm there.

Originally created by @jonocodes on GitHub (Apr 22, 2024). Original GitHub issue: https://github.com/cypht-org/cypht/issues/974 Originally assigned to: @Shadow243 on GitHub. ## 💬 Question  First off, thanks for this app. I'm very happy to have found it, as it fits the needs I am looking for on my new server. I have about 10 IMAP accounts. I would like to set them up with a config file instead of using the UI. It looks like this can be done for only a single IMAP server via env var IMAP_AUTH_*. Is there a recommended way to do this? Perhaps set it up once and use USER_CONFIG_TYPE=file then copy that file to my new system? Side note I am running this in NixOS which I only mention because declarative configs are the norm there.

kerem commented

2026-02-25 21:35:15 +03:00

Author

Owner

@marclaporte commented on GitHub (Apr 23, 2024):

Thank you for the kind words.

For .env, let's ask the author @Shadow243 for some advice.

@marclaporte commented on GitHub (Apr 23, 2024): Thank you for the kind words. Related: https://github.com/cypht-org/cypht/issues/470 For .env, let's ask the author @Shadow243 for some advice.

kerem commented

2026-02-25 21:35:15 +03:00

Author

Owner

@jonocodes commented on GitHub (Apr 24, 2024):

Where are the imap creds stored now? I was not able to quickly find them. I saw there were some blobs in the mysql db. There?

@jonocodes commented on GitHub (Apr 24, 2024): Where are the imap creds stored now? I was not able to quickly find them. I saw there were some blobs in the mysql db. There?

kerem commented

2026-02-25 21:35:15 +03:00

Author

Owner

@Shadow243 commented on GitHub (Apr 24, 2024):

Thank you for the kind words.

Related: #470

For .env, let's ask the author @Shadow243 for some advice.

IMAP_AUTH_ is primarily used when AUTH_TYPE=IMAP to authenticate during the connection (on the login page) and of course to automatically add the server once connected.

Configuring multiple accounts via .env will complicate this file, but I think we can do it through a configuration file, as we did for LDAP Contact (config/ldap.php).

'imap_accounts' => [
    'Personal' => [
        'server'  => '',
        'port' => '',
        'tls' => '',
        'sieve' => '',
        'username' => '',
        'pwd' => ''
    ],
    'OtherName' => [
        'server'  => '',
        'port' => '',
        'tls' => '',
        'sieve' => '',
        'username' => '',
        'pwd' => ''
    ],
]

This could allow us to anticipate the accounts (servers) to add on the server page automatically while retaining the IMAP_AUTH_ functionality with its initial function.

@Shadow243 commented on GitHub (Apr 24, 2024): > Thank you for the kind words. > > Related: #470 > > For .env, let's ask the author @Shadow243 for some advice. IMAP_AUTH_ is primarily used when AUTH_TYPE=IMAP to authenticate during the connection (on the login page) and of course to automatically add the server once connected. Configuring multiple accounts via .env will complicate this file, but I think we can do it through a configuration file, as we did for LDAP Contact (config/ldap.php). ```php 'imap_accounts' => [ 'Personal' => [ 'server' => '', 'port' => '', 'tls' => '', 'sieve' => '', 'username' => '', 'pwd' => '' ], 'OtherName' => [ 'server' => '', 'port' => '', 'tls' => '', 'sieve' => '', 'username' => '', 'pwd' => '' ], ] ``` This could allow us to anticipate the accounts (servers) to add on the server page automatically while retaining the IMAP_AUTH_ functionality with its initial function.

kerem commented

2026-02-25 21:35:15 +03:00

Author

Owner

@Shadow243 commented on GitHub (Apr 24, 2024):

Thank you for the kind words.
Related: #470
For .env, let's ask the author @Shadow243 for some advice.

IMAP_AUTH_ is primarily used when AUTH_TYPE=IMAP to authenticate during the connection (on the login page) and of course to automatically add the server once connected.

Configuring multiple accounts via .env will complicate this file, but I think we can do it through a configuration file, as we did for LDAP Contact (config/ldap.php).
'imap_accounts' => [
    'Personal' => [
        'server'  => '',
        'port' => '',
        'tls' => '',
        'sieve' => '',
        'username' => '',
        'pwd' => ''
    ],
    'OtherName' => [
        'server'  => '',
        'port' => '',
        'tls' => '',
        'sieve' => '',
        'username' => '',
        'pwd' => ''
    ],
]
This could allow us to anticipate the accounts (servers) to add on the server page automatically while retaining the IMAP_AUTH_ functionality with its initial function.

However, this scenario does not work in all cases. For example, we may have 10 IMAP accounts, but each account belongs to a different person. Therefore, each person must log in with their own account. By putting the accounts in the configuration file, everyone who is logged in will have access. However, this works in the case of someone managing (centralizing) his accounts in one place for himself

@Shadow243 commented on GitHub (Apr 24, 2024): > > Thank you for the kind words. > > Related: #470 > > For .env, let's ask the author @Shadow243 for some advice. > > IMAP_AUTH_ is primarily used when AUTH_TYPE=IMAP to authenticate during the connection (on the login page) and of course to automatically add the server once connected. > > Configuring multiple accounts via .env will complicate this file, but I think we can do it through a configuration file, as we did for LDAP Contact (config/ldap.php). > > ``` > 'imap_accounts' => [ > 'Personal' => [ > 'server' => '', > 'port' => '', > 'tls' => '', > 'sieve' => '', > 'username' => '', > 'pwd' => '' > ], > 'OtherName' => [ > 'server' => '', > 'port' => '', > 'tls' => '', > 'sieve' => '', > 'username' => '', > 'pwd' => '' > ], > ] > ``` > > This could allow us to anticipate the accounts (servers) to add on the server page automatically while retaining the IMAP_AUTH_ functionality with its initial function. However, this scenario does not work in all cases. For example, we may have 10 IMAP accounts, but each account belongs to a different person. Therefore, each person must log in with their own account. By putting the accounts in the configuration file, everyone who is logged in will have access. However, this works in the case of someone managing (centralizing) his accounts in one place for himself

kerem commented

2026-02-25 21:35:15 +03:00

Author

Owner

@jonocodes commented on GitHub (Apr 24, 2024):

@Shadow243 my goal is to use the unified inbox with all these accounts, so no separate logins.

@jonocodes commented on GitHub (Apr 24, 2024): @Shadow243 my goal is to use the unified inbox with all these accounts, so no separate logins.

kerem commented

2026-02-25 21:35:15 +03:00

Author

Owner

@marclaporte commented on GitHub (Apr 24, 2024):

@jonocodes Will more than one person use your Cypht instance?

@marclaporte commented on GitHub (Apr 24, 2024): @jonocodes Will more than one person use your Cypht instance?

kerem commented

2026-02-25 21:35:15 +03:00

Author

Owner

@jonocodes commented on GitHub (Apr 24, 2024):

@jonocodes Will more than one person use your Cypht instance?

My current use of cypht is much like how I use Thunderbird. I have a single profile/user. I use thunderbird to access all my accounts when at my main desktop. And I use a selfhosted cypht to access all my email accounts when I am away from my desktop.

@jonocodes commented on GitHub (Apr 24, 2024): > @jonocodes Will more than one person use your Cypht instance? My current use of cypht is much like how I use Thunderbird. I have a single profile/user. I use thunderbird to access all my accounts when at my main desktop. And I use a selfhosted cypht to access all my email accounts when I am away from my desktop.

kerem commented

2026-02-25 21:35:15 +03:00

Author

Owner

@marclaporte commented on GitHub (Apr 25, 2024):

Ok so then the .env should work for you. Please let us know how it goes.

@marclaporte commented on GitHub (Apr 25, 2024): Ok so then the .env should work for you. Please let us know how it goes.

kerem commented

2026-02-25 21:35:15 +03:00

Author

Owner

@jonocodes commented on GitHub (Apr 25, 2024):

Ok so then the .env should work for you. Please let us know how it goes.

I don't think I understand. Are you saying the env file ready supports this? Or that I should develop that support? My understanding is it does not support it now.

@jonocodes commented on GitHub (Apr 25, 2024): > Ok so then the .env should work for you. Please let us know how it goes. I don't think I understand. Are you saying the env file ready supports this? Or that I should develop that support? My understanding is it does not support it now.

kerem commented

2026-02-25 21:35:15 +03:00

Author

Owner

@marclaporte commented on GitHub (Apr 25, 2024):

@Shadow243 wrote: "However, this works in the case of someone managing (centralizing) his accounts in one place for himself"

So please try and let us know :-)

@marclaporte commented on GitHub (Apr 25, 2024): @Shadow243 wrote: "However, this works in the case of someone managing (centralizing) his accounts in one place for himself" So please try and let us know :-)

kerem commented

2026-02-25 21:35:15 +03:00

Author

Owner

@Shadow243 commented on GitHub (Apr 25, 2024):

@Shadow243 wrote: "However, this works in the case of someone managing (centralizing) his accounts in one place for himself"

So please try and let us know :-)

I'm now working on a good way to handle this even with multiple users using one instance.

@Shadow243 commented on GitHub (Apr 25, 2024): > @Shadow243 wrote: "However, this works in the case of someone managing (centralizing) his accounts in one place for himself" > > > > So please try and let us know :-) I'm now working on a good way to handle this even with multiple users using one instance.

kerem commented

2026-02-25 21:35:15 +03:00

Author

Owner

@kroky commented on GitHub (Apr 25, 2024):

Is there a recommended way to do this? Perhaps set it up once and use USER_CONFIG_TYPE=file then copy that file to my new system?

Both config storage options would work - file or db as long as you copy the file or db to your new system and use the same user password for your account login to cypht (password is used as an encryption key for the data stored in local file or db). To keep things simpler, I suggest you use file storage for config and copy your user settings dir to the new system.

Mixing user configuration with system configuration from env or config php files might get tricky here...

@kroky commented on GitHub (Apr 25, 2024): > Is there a recommended way to do this? Perhaps set it up once and use USER_CONFIG_TYPE=file then copy that file to my new system? Both config storage options would work - file or db as long as you copy the file or db to your new system and use the same user password for your account login to cypht (password is used as an encryption key for the data stored in local file or db). To keep things simpler, I suggest you use file storage for config and copy your user settings dir to the new system. Mixing user configuration with system configuration from env or config php files might get tricky here...

kerem commented

2026-02-25 21:35:15 +03:00

Author

Owner

@jonocodes commented on GitHub (Apr 26, 2024):

I am trying to understand the file storage option. I ran this

version: '3'
services:
  db:
    image: mariadb:10
    volumes:
      - ./db:/var/lib/mysql
    environment:
      - MYSQL_ROOT_PASSWORD=root_password
      - MYSQL_DATABASE=cypht
      - MYSQL_USER=cypht
      - MYSQL_PASSWORD=cypht_password
  cypht:
    image: sailfrog/cypht-docker:latest
    volumes:
      - ./cypht/users:/var/lib/hm3/users
    ports:
      - "81:80"
    environment:
      - CYPHT_AUTH_USERNAME=admin
      - CYPHT_AUTH_PASSWORD=admin_password
      - CYPHT_DB_CONNECTION_TYPE=host
      - CYPHT_DB_HOST=db
      - CYPHT_DB_NAME=cypht
      - CYPHT_DB_USER=cypht
      - CYPHT_DB_PASS=cypht_password
      - CYPHT_SESSION_TYPE=DB
      - CYPHT_USER_CONFIG_TYPE=file

Then logged in and created some imap accounts. Now here is what the file system looks like:

/var/lib/hm3 # ls -lR
.:
total 3
drwxr-xr-x    2 www-data www-data         2 Apr 26 18:35 app_data
drwxr-xr-x    2 www-data www-data         2 Apr 26 18:35 attachments
drwxr-xr-x    2 www-data www-data         3 Apr 26 18:36 users

./app_data:
total 0

./attachments:
total 0

./users:
total 5
-rw-r--r--    1 www-data www-data      2716 Apr 26 19:41 admin.txt

of course admin.txt is giberish. Is this the encrypted payload that has all the imap credentials in it? And if so, is there a manual way for me to decrypt it outside cypht and see whats there?

@jonocodes commented on GitHub (Apr 26, 2024): I am trying to understand the file storage option. I ran this ``` version: '3' services: db: image: mariadb:10 volumes: - ./db:/var/lib/mysql environment: - MYSQL_ROOT_PASSWORD=root_password - MYSQL_DATABASE=cypht - MYSQL_USER=cypht - MYSQL_PASSWORD=cypht_password cypht: image: sailfrog/cypht-docker:latest volumes: - ./cypht/users:/var/lib/hm3/users ports: - "81:80" environment: - CYPHT_AUTH_USERNAME=admin - CYPHT_AUTH_PASSWORD=admin_password - CYPHT_DB_CONNECTION_TYPE=host - CYPHT_DB_HOST=db - CYPHT_DB_NAME=cypht - CYPHT_DB_USER=cypht - CYPHT_DB_PASS=cypht_password - CYPHT_SESSION_TYPE=DB - CYPHT_USER_CONFIG_TYPE=file ``` Then logged in and created some imap accounts. Now here is what the file system looks like: ``` /var/lib/hm3 # ls -lR .: total 3 drwxr-xr-x 2 www-data www-data 2 Apr 26 18:35 app_data drwxr-xr-x 2 www-data www-data 2 Apr 26 18:35 attachments drwxr-xr-x 2 www-data www-data 3 Apr 26 18:36 users ./app_data: total 0 ./attachments: total 0 ./users: total 5 -rw-r--r-- 1 www-data www-data 2716 Apr 26 19:41 admin.txt ``` of course admin.txt is giberish. Is this the encrypted payload that has all the imap credentials in it? And if so, is there a manual way for me to decrypt it outside cypht and see whats there?

kerem commented

2026-02-25 21:35:15 +03:00

Author

Owner

@kroky commented on GitHub (Apr 29, 2024):

Yes, admin.txt is the encrypted storage for admin user settings including server details. Decryption is possible using the https://github.com/cypht-org/cypht/blob/master/lib/crypt.php#L75 Hm_Crypt_Base::plaintext function and passing your password as a key. You could also do it outside PHP using openssl descrypt but you should construct the initialization vector and other parameters manually from the encrypted string like the PHP function does.

@kroky commented on GitHub (Apr 29, 2024): Yes, admin.txt is the encrypted storage for admin user settings including server details. Decryption is possible using the https://github.com/cypht-org/cypht/blob/master/lib/crypt.php#L75 Hm_Crypt_Base::plaintext function and passing your password as a key. You could also do it outside PHP using openssl descrypt but you should construct the initialization vector and other parameters manually from the encrypted string like the PHP function does.

kerem commented

2026-02-25 21:35:16 +03:00

Author

Owner

@jonocodes commented on GitHub (May 2, 2024):

Yes, admin.txt is the encrypted storage for admin user settings including server details. Decryption is possible using the master/lib/crypt.php#L75 Hm_Crypt_Base::plaintext function and passing your password as a key. You could also do it outside PHP using openssl descrypt but you should construct the initialization vector and other parameters manually from the encrypted string like the PHP function does.

Ah. So the encrypted blob is the part I am trying to work around. Why is it encrypted? I understand perhaps wanting to hide the password, but the whole file? Is this a common practice in other like-software?
If blob was exposed and had an understood structure (yaml, json, etc) we could just edit and add accounts there.

@jonocodes commented on GitHub (May 2, 2024): > Yes, admin.txt is the encrypted storage for admin user settings including server details. Decryption is possible using the [`master`/lib/crypt.php#L75](https://github.com/cypht-org/cypht/blob/master/lib/crypt.php?rgh-link-date=2024-04-29T06%3A59%3A27Z#L75) Hm_Crypt_Base::plaintext function and passing your password as a key. You could also do it outside PHP using openssl descrypt but you should construct the initialization vector and other parameters manually from the encrypted string like the PHP function does. Ah. So the encrypted blob is the part I am trying to work around. Why is it encrypted? I understand perhaps wanting to hide the password, but the whole file? Is this a common practice in other like-software? If blob was exposed and had an understood structure (yaml, json, etc) we could just edit and add accounts there.

kerem commented

2026-02-25 21:35:16 +03:00

Author

Owner

@marclaporte commented on GitHub (May 2, 2024):

Why is it encrypted? I understand perhaps wanting to hide the password, but the whole file? Is this a common practice in other like-software?

https://www.cypht.org/security.html
https://en.wikipedia.org/wiki/Zero_trust_security_model

@marclaporte commented on GitHub (May 2, 2024): > Why is it encrypted? I understand perhaps wanting to hide the password, but the whole file? Is this a common practice in other like-software? https://www.cypht.org/security.html https://en.wikipedia.org/wiki/Zero_trust_security_model

kerem commented

2026-02-25 21:35:16 +03:00

Author

Owner

@kroky commented on GitHub (May 2, 2024):

Server-side storage encryption is needed to make it more secure against tampering or data-leak attacks. You can still make a small script to encrypt/decrypt the file and add the info you need manually. We can also think about adding this in scripts folder, so you can use the command line to add accounts and do other config modification programatically.

@kroky commented on GitHub (May 2, 2024): Server-side storage encryption is needed to make it more secure against tampering or data-leak attacks. You can still make a small script to encrypt/decrypt the file and add the info you need manually. We can also think about adding this in scripts folder, so you can use the command line to add accounts and do other config modification programatically.

kerem commented

2026-02-25 21:35:16 +03:00

Author

Owner

@jonocodes commented on GitHub (May 2, 2024):

I understand the sentiment but are there other projects that encrypt whole config files? Is the concern that you are trying to protect things like imap host and username as well as the password? If you want to protect data, thats one thing. But I would think the structure of the config (ie- where you put what keys etc) should be exposed, like the other configs like the config/app.php or hm3.ini . This is also how certs and ssh keys work.

But without ruffling too many feathers, yes, perhaps adding an encrypt/decrypt script would be the lightest touch here.

@jonocodes commented on GitHub (May 2, 2024): I understand the sentiment but are there other projects that encrypt whole config files? Is the concern that you are trying to protect things like imap host and username as well as the password? If you want to protect data, thats one thing. But I would think the structure of the config (ie- where you put what keys etc) should be exposed, like the other configs like the config/app.php or hm3.ini . This is also how certs and ssh keys work. But without ruffling too many feathers, yes, perhaps adding an encrypt/decrypt script would be the lightest touch here.

kerem commented

2026-02-25 21:35:16 +03:00

Author

Owner

@marclaporte commented on GitHub (May 5, 2024):

I understand the sentiment but are there other projects that encrypt whole config files?

@jonocodes It was like that when I started getting involved in Cypht. I don't know the precise background information / motivation / trade-offs, etc. In any case, it's an Open Source community project, and a do-ocracy, so let's work together to make Cypht better for various use cases :-)

@marclaporte commented on GitHub (May 5, 2024): > I understand the sentiment but are there other projects that encrypt whole config files? @jonocodes It was like that when I started getting involved in Cypht. I don't know the precise background information / motivation / trade-offs, etc. In any case, it's an Open Source community project, and a do-ocracy, so let's work together to make Cypht better for various use cases :-)

kerem commented

2026-02-25 21:35:16 +03:00

Author

Owner

@jonocodes commented on GitHub (May 5, 2024):

@jonocodes It was like that when I started getting involved in Cypht. I don't know the precise background information / motivation / trade-offs, etc. In any case, it's an Open Source community project, and a do-ocracy, so let's work together to make Cypht better for various use cases :-)

Yes. I may put some scripting around this to automate at some point.
Side note, I am also looking at introducing a Makefile or something like it that will help with these kinds of operations.

@jonocodes commented on GitHub (May 5, 2024): > @jonocodes It was like that when I started getting involved in Cypht. I don't know the precise background information / motivation / trade-offs, etc. In any case, it's an Open Source community project, and a do-ocracy, so let's work together to make Cypht better for various use cases :-) Yes. I may put some scripting around this to automate at some point. Side note, I am also looking at introducing a Makefile or something like it that will help with these kinds of operations.

kerem commented

2026-02-25 21:35:16 +03:00

Author

Owner

@kroky commented on GitHub (May 7, 2024):

Exposing the config file structure and encrypting only the sensitive information might be a configuration thing for Cypht 3.0. As Marc said, encryption of that file was pretty much around for the whole cypht lifetime, so not an easy one to change.

@kroky commented on GitHub (May 7, 2024): Exposing the config file structure and encrypting only the sensitive information might be a configuration thing for Cypht 3.0. As Marc said, encryption of that file was pretty much around for the whole cypht lifetime, so not an easy one to change.

kerem commented

2026-02-25 21:35:16 +03:00

Author

Owner

@marclaporte commented on GitHub (Jul 3, 2024):

@marclaporte commented on GitHub (Jul 3, 2024): Related: https://github.com/cypht-org/cypht/pull/976

kerem commented

2026-02-25 21:35:16 +03:00

Author

Owner

@marclaporte commented on GitHub (Sep 12, 2024):

https://github.com/cypht-org/cypht/pull/976 has been merged in for easier bulk import of accounts.

Keeping this issue open as further work is needed to make it easier to sync configs between Cypht and other tools (like a desktop email client)

@marclaporte commented on GitHub (Sep 12, 2024): https://github.com/cypht-org/cypht/pull/976 has been merged in for easier bulk import of accounts. Keeping this issue open as further work is needed to make it easier to sync configs between Cypht and other tools (like a desktop email client)

kerem commented

2026-02-25 21:35:16 +03:00

Author

Owner

@marclaporte commented on GitHub (Sep 4, 2025):

Just FYI: In Tiki, preferences (configuration settings) can be imported and exported via YAML. Ref: https://doc.tiki.org/Export-Profiles

@marclaporte commented on GitHub (Sep 4, 2025): Just FYI: In Tiki, preferences (configuration settings) can be imported and exported via YAML. Ref: https://doc.tiki.org/Export-Profiles

Rows
Columns

[GH-ISSUE #974] Declarative config for multiple accounts #523

💬 Question