.env files vs arrays vs json

[Anoniem: 80910]

Beste leute,

ik zit met een idee waar ik graag een discussie over wil starten.
Nu heb ik PHPstorm, en de nieuwe versie mogen uitproberen met AI assist.

Momenteel gebruik ik in mijn framework geen .env files, maar had ik het eerst in een "config.json" bestand staan. daar stond bijvoorbeeld ook per environment ingesteld de database verbindingen (in json gescheiden met een property: development, staging, production, test, replica).

Nu was het zo, dat ik daar een update voor heb gemaakt en nu zit de config verspreid over meerde subconfigs "relaties" in een soort crud systeem voor json objecten.

JSON:

{
    "System": {
        "Doctrine": {
            "Environment": [
                {
                    "uuid": "74ebd5fa-8800-4312-a0e5-04d25e52f8c3",
                    "#class": "System.Doctrine.Environment",
                    "name": "system",
                    "environment": "*",
                    "driver": "pdo_sqlite",
                    "path": "{{config('project.dir.data')}}Sqlite\/System.db",
                    "logging": true
                },
                ...
}

Nu heb ik de ai verteld over mijn framework en deze kan best goed zien, maar kwamen we er met de discussie over jawel, wat de beste plek is om credentials op te slaan is.

De ai vond .env het veiligst zolang die niet wordt gepushed naar versie beheer. ik vond de json opzich ook niet verkeerd want dat is nu data en dat wordt ook niet gepushed naar versie beheer (kan wel, ander verhaal...) maar dat zou een opzichzelfstaande private branch zijn, puur voor backup van data (los van de applicatie etc...)

De reden dat ik het wel in json heb en niet in een .env file is omdat ik een cms systeem wil schrijven en dit aanpasbaar wil hebben in het cms systeem (bijvoorbeeld een nieuwe connectie toevoegen...)

Dus dan is .env niet echt handig om mee te werken.

De AI vond dat je maar een script moest automatiseren om de .env aan te passen en deze de juiste rechten moet geven. en het anders handmatig aanpassen van de .env file is.

Json laat het toe dat je oneindig veel verbindingen als object in een nette array kan zetten, bij de .env file wordt het een zooitje want key -> value

Ik heb al een taskrunner gemaakt (die als admin wordt uitgevoerd) die bijvoorbeeld de task krijgt om de .env aan te passen. Maarja ik was niet van plan om de complete config in de .env file te zettten want dat kunnen ook objecten zijn (loggers bijvoorbeeld), maar credentials zou wellicht kunnen.

JSON:

{
    "System": {
        "Config": {
            "Log": {
                "Handler": [
                    {
                        "uuid": "0a36ca31-458b-40d3-845c-be81b59a0ad0",
                        "#class": "System.Config.Log.Handler",
                        "options": {
                            "class": "Monolog\\Handler\\StreamHandler",
                            "parameters": [
                                "{{config('project.dir.log')}}app.log",
                                "DEBUG"
                            ]
                        }
                    },
                    ...

JSON:

{
    "System": {
        "Config": {
            "Log": {
                "Processor": [
                    {
                        "uuid": "d90d10f6-33c8-4aaf-a501-240bce0fcfbe",
                        "#class": "System.Config.Log.Processor",
                        "options": {
                            "class": "Monolog\\Processor\\PsrLogMessageProcessor",
                            "parameters": [
                                null,
                                false
                            ]
                        }
                    }
                ]
            }
        }
    }
}

Nadeel van .env file is, zijn ze binnen en scannen heel makkelijk op de .env en je vind ze allemaal op het systeem.

Nu heb ik al lopen denken maar je hebt altijd een master password in plain text nodig op de server. De hacker moet dan in het geval van mijn methode precies weten welk json bestand het is, ik kan het ook nog encrypted opslaan, heb je ook nog een key bestand en een scriptje nodig omdat te decoden wat eigenlijk inhoud dat je als hacker verstand van mijn framework /cms moet hebben. Nu heb je AI, maar die moet dat natuurlijk niet prijs geven.

de .env file zou natuurlijk ook encrypted kunnen worden, moet je weer de key zoeken en scriptje schrijven om het te decrypten. (tis iets extra werk, waardoor sommige hackers wellicht afhaken) vooral als je 1 miljoen keys hebt in die key directory om het nog lastiger te maken?

Ik heb eigenlijk geen zin om het in een .env file te doen. het json crud systeem heeft zijn eigen docker volume en kan eventueel zijn eigen prive repository hebben, of zou je die volume zippen/rarren en de backup ergens neer zetten (rar was nog niet gekraakt toch met password ?) ?

Wellicht is het nog veiliger om een wachtwoord te gebruiken van substrings van code uit verschillende bestanden waardoor je ook geen .env file nodig hebt en die eens in de maand te laten roteren en mailen.

AL met al was ik al van plan om een tweede server er naast te zetten waar de encrypted data komt te staan, maarja dan blijf je met dat ene wachtwoord, wat wellicht uit de code moet komen...

Dus is .env beter en hoe het te verbergen voor de hacker ?

[ Voor 19% gewijzigd door Anoniem: 80910 op 10-12-2023 01:07 . Reden: json voorbeeld ]

[eLScha]

Ik krijg het idee dat je meerdere soorten config bij elkaar probeert te gooien. Alles wat environment-afhankelijk is staat normaal gezien in een .env-file. Zaken die je vanuit de admin wilt aanpassen staan niet in een .env-file.

Kijk je naar Laravel, dan wordt de config van allerlei services opgebouwd via php-bestanden. In die php-bestanden kun je ook gebruik maken van data uit je .env-file.

Kijk je naar Magento 2, dan zie daar een env.php met allerlei config. Daar staan gegevens in voor de MySQL-database en Redis-database bijvoorbeeld, maar je kunt er ook waarden inzetten die bedoeld zijn voor de Magento-admin.

Wellicht kunnen een van deze voorbeelden je verder helpen.

[Anoniem: 80910]

eLScha schreef op zondag 10 december 2023 @ 01:07:
Ik krijg het idee dat je meerdere soorten config bij elkaar probeert te gooien. Alles wat environment-afhankelijk is staat normaal gezien in een .env-file. Zaken die je vanuit de admin wilt aanpassen staan niet in een .env-file.

Kijk je naar Laravel, dan wordt de config van allerlei services opgebouwd via php-bestanden. In die php-bestanden kun je ook gebruik maken van data uit je .env-file.

Kijk je naar Magento 2, dan zie daar een env.php met allerlei config. Daar staan gegevens in voor de MySQL-database en Redis-database bijvoorbeeld, maar je kunt er ook waarden inzetten die bedoeld zijn voor de Magento-admin.

Wellicht kunnen een van deze voorbeelden je verder helpen.

Ik heb Laravel bij mijn vorige werkgever gebruikt, daarnaast symfony 2 en synfony 4, 5 mee gewerkt, ik zal eens kijken naar dat van Magento 2, Wordpress, Drupal enzo, goeie even kijken bij de buren...

Daarnaast moeten er meerdere domeinen in mijn cms beheert worden wellicht ook met meerdere databases, key, value pair is dan niet handig lijkt mij

Dit is mijn config file:

JSON:

{
    "System": {
        "Config": [
            {
                "uuid": "b10aac4f-91c6-4c16-b4cd-6f8a504dc64e",
                "#class": "System.Config",
                "server": "*",
                "service": "*",
                "ramdisk": "*",
                "email": "*",
                "response": "*",
                "autoload": "*",
                "framework": "*",
                "doctrine": "*",
                "log": "*"
            }
        ]
    }
}

Hieronder een object beschrijving van het data bestand, (hier wil ik formulieren en lijsten mee automatisch kunnen genereren in mijn cms)

JSON:

{
    "Node": {
        "#class": "System.Config",
        "type": "object",
        "property": [
            {
                "name": "autoload",
                "type": "uuid",
                "relation": true,
                "is_multiple": false
            },
            {
                "name": "doctrine",
                "type": "uuid",
                "relation": true,
                "is_multiple": false
            },
            {
                "name": "email",
                "type": "uuid",
                "relation": true,
                "is_multiple": false
            },
            {
                "name": "framework",
                "type": "uuid",
                "relation": true,
                "is_multiple": false
            },
            {
                "name": "log",
                "type": "array",
                "relation": true,
                "is_multiple": true
            },
            {
                "name": "ramdisk",
                "type": "uuid",
                "relation": true,
                "is_multiple": false
            },
            {
                "name": "response",
                "type": "uuid",
                "relation": true,
                "is_multiple": false
            },
            {
                "name": "server",
                "type": "uuid",
                "relation": true,
                "is_multiple": false
            },
            {
                "name": "service",
                "type": "uuid",
                "relation": true,
                "is_multiple": false
            },
            {
                "name": "uuid",
                "type": "uuid"
            },
            {
                "name": "#class",
                "type": "string"
            }
        ]
    },
    "is.unique": [
        "#class"
    ],
    "relation": [
        {
            "type": "one-one",
            "class": "System.Autoload",
            "attribute": "autoload"
        },
        {
            "type": "one-one",
            "class": "System.Doctrine",
            "attribute": "doctrine"
        },
        {
            "type": "one-one",
            "class": "System.Config.Email",
            "attribute": "email"
        },
        {
            "type": "one-one",
            "class": "System.Framework",
            "attribute": "framework"
        },
        {
            "type": "one-many",
            "class": "System.Config.Log",
            "attribute": "log",
            "sort": {
                "name": "ASC"
            },
            "output": {
                "filter":[
                    "R3m:Io:Output:Filter:System:Config:log"
                ]
            }
        },
        {
            "type": "one-one",
            "class": "System.Config.Ramdisk",
            "attribute": "ramdisk"
        },
        {
            "type": "one-one",
            "class": "System.Config.Response",
            "attribute": "response"
        },
        {
            "type": "one-one",
            "class": "System.Server",
            "attribute": "server"
        },
        {
            "type": "one-one",
            "class": "System.Config.Service",
            "attribute": "service"
        }
    ]
}

Wat ik nog vergeten ben is: met json heb ik ook validatie bij updates /inserts en rechten bij "expose" (er wordt rol gebaseerd gekeken welke properties het object weergeeft) dat heb je met een .env niet

Het idee is dat in mijn CMS geen main database heeft, maar dit JSON CRUD systeem als hoofdsysteem met daarin de credentials om te verbinden met meerde databases op meerdere domeinen /subdomeinen

Je weet ook dat als je een CMS hebt, dat eigenlijk 1x per maand of eigenlijk nog beter 1x per interval (risico) zo'n wachtwoord te wijzigen, nu is er ook ip whitelisting van de andere kant, maar toch). Dat houdt in dat je elke maand een developer moet inschakelen om je cms te updaten, terwijl je dat met mijn manier zelf kunt.

Ik heb gezien bij wordpress dat je een developer moet inhuren omdat te doen, dus we zijn met zn allen lekker bezig aangezien er 18.9% van alle websites wordpress zijn?

[ Voor 80% gewijzigd door Anoniem: 80910 op 10-12-2023 02:16 . Reden: beter argument ]