Declarative config for multiple accounts

[jonocodes]

Declarative config for multiple accounts

[Shadow243]

@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.

[marclaporte]

Thank you for the kind words.

Related: #470

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

[jonocodes]

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?

[Shadow243]

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]

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

[jonocodes]

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

[marclaporte]

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

[jonocodes]

@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.

[marclaporte]

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

[jonocodes]

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.

[marclaporte]

@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 :-)

[kroky]

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...

[jonocodes]

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?

[kroky]

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.

[jonocodes]

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.

[marclaporte]

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

[kroky]

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.

[jonocodes]

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.

[marclaporte]

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 :-)

[jonocodes]

@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.

[kroky]

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.