I’m doing a quick article on the subject even though it is probably known by most. Nevertheless, it happens to me while discussing with other developers that not everyone knows the auto_prepend_file system which can be a practical way to manage its constants.
Management of PHP constants according to the environment [DEV, PROD, recipe, etc.]
As we know, in many development projects [and PHP projects are no exception] you will have to manage a certain number of constants [path, urls, accounts, etc.]. And these constants are generally different between development and production.
We can collect these constants in a configuration file inside a project, which can be a good way to do it, but how to manage the fact of taking the constants of development in development and those of production in prod without put a series of if?
Auto_prepend_file via php.ini
There is a fairly simple method, which can be effective in this case.
Constants must be centralized in a PHP file. This already has the merit of putting them all in the same place.
Next, we will use the “ auto_prepend_file ” property from the php.ini configuration file. This will have the effect of loading this file each time a PHP file is called, before the latter. Thus, we are sure to have all our constants before doing the desired PHP processing [like for an include].
In the php.ini, the syntax is as follows by changing the path to the file to put yours:
auto_prepend_file = /var/www/intranet/lib/config/prod_config.php
In the path above, you see in the file name that there is “prod”. You can create two files, a dev_config.php and a prod_config.php. It is then sufficient, depending on the server to be configured, to point to one or the other. As you know, there is a php.ini for the apache server, and one for the CLI. You can choose to use the same, or have a config file dedicated to the CLI, the operation is the same.
Regarding translations: My native language is English. Because this is a free and open-source hobby project which generates zero income, and translatable content is likely to change as the features and functionality supported by the project changes, it doesn't make sense for me to spend money for translations. Because I'm the sole author/developer/maintainer for the project and I'm not a ployglot, any translations I produce are very likely to contain errors. Sorry, but realistically, that won't ever change. If you find any such errors/typos/mistakes/etc, your assistance to correct them would be very much appreciated. Pull requests are invited and encouraged. Otherwise, if you find these errors too much to handle, just stick with the original English source. If a translation is irredeemably incomprehensible, let me know which, and I can delete it. If you're not sure how to perform pull requests, ask. I can help.
1. SEPATAH KATA
CIDRAM [Classless Inter-Domain Routing Access Manager] adalah skrip PHP dirancang untuk melindungi situs oleh memblokir permintaan-permintaan berasal dari alamat IP yang dianggap sumber lalu lintas yang tidak diinginkan, termasuk [tapi tidak terbatas pada] lalu lintas dari jalur akses yang tidak manusia, layanan cloud, spambots, pencakar/scrapers, dll. Hal ini dilakukan melalui menghitung kisaran CIDR alamat IP dipasok dari permintaan dan mencoba untuk mencocokkan ini kisaran CIDR terhadap file tanda tangan [file tanda tangan ini berisi daftar CIDR alamat IP dianggap sumber lalu lintas yang tidak diinginkan]; Jika dicocokkan, permintaan yang diblokir.
[Lihat: ].
CIDRAM HAK CIPTA 2016 dan di atas GNU/GPLv2 oleh Caleb M [Maikuolan].
Skrip ini adalah perangkat lunak gratis; Anda dapat mendistribusikan kembali dan/atau memodifikasinya dalam batasan dari GNU General Public License, seperti di publikasikan dari Free Software Foundation; baik versi 2 dari License, atau [dalam opsi Anda] versi selanjutnya apapun. Skrip ini didistribusikan untuk harapan dapat digunakan tapi TANPA JAMINAN; tanpa walaupun garansi dari DIPERJUALBELIKAN atau KECOCOKAN UNTUK TUJUAN TERTENTU. Mohon Lihat GNU General Public Licence untuk lebih detail, terletak di file
fields
├─ID ["ID"]
├─ScriptIdent ["Versi Skrip"]
├─DateTime ["Tanggal/Waktu"]
├─IPAddr ["Alamat IP"]
├─IPAddrResolved ["Alamat IP [Terselesaikan]"]
├─Query ["Kueri"]
├─Referrer ["Halaman Mengacu"]
├─UA ["Agen Pengguna"]
├─UALC ["Agen Pengguna [huruf kecil]"]
├─SignatureCount ["Penghitungan tanda tangan"]
├─Signatures ["Referensi tanda tangan"]
├─WhyReason ["Mengapa diblokir"]
├─ReasonMessage ["Mengapa diblokir [terperinci]"]
├─rURI ["Direkonstruksi URI"]
├─Infractions ["Pelanggaran"]
├─ASNLookup ["Pencarian ASN"]
├─CCLookup ["Pencarian kode negara"]
├─Verified ["Identitas terverifikasi"]
├─Expired ["Kedaluwarsa"]
├─Ignored ["Diabaikan"]
├─Request_Method ["Metode permintaan"]
├─Protocol ["Protokol"]
├─Hostname ["Nama host"]
└─CAPTCHA ["Status CAPTCHA"]
- //www.gnu.org/licenses/.
- //opensource.org/licenses/.
Dokumen ini dan paket terhubung di dalamnya dapat di unduh secara gratis dari:
- GitHub.
- Bitbucket.
- SourceForge.
2. BAGAIMANA CARA MENGINSTAL
2.0 MENGINSTAL SECARA MANUAL
Pertama, Anda memerlukan salinan CIDRAM baru. Anda dapat mengunduh arsip yang barisi CIDRAM versi terbaru dari repositori CIDRAM/CIDRAM. Lebih spesifik, Anda memerlukan salinan direktori "vault" [semuanya dari arsip selain direktori "vault" dan isinya dapat dihapus atau diabaikan dengan aman].
Sebelum v3, Anda perlu menginstal CIDRAM di suatu tempat di dalam root publik Anda agar dapat mengakses front-end CIDRAM. Namun, dari v3 dan seterusnya, ini tidak perlu, dan untuk memaksimalkan keamanan dan untuk mencegah akses yang tidak diotorisasi ke CIDRAM dan filenya, disarankan untuk menginstal CIDRAM di luar root publik Anda. Tidak masalah persis dimana Anda memilih untuk menginstal CIDRAM, selama PHP dapat mengaksesnya, dan selama itu di suatu tempat yang cukup aman dan Anda puas dengan. Juga tidak perlu mempertahankan nama direktori "vault", jadi Anda dapat mengganti nama "vault" menjadi nama apapun yang Anda inginkan [tetapi demi kenyamanan, dokumentasi akan terus merujuknya sebagai direktori "vault"].
Saat Anda siap, upload direktori "vault" ke lokasi yang Anda pilih, dan pastikan direktori tersebut memiliki izin yang diperlukan agar PHP dapat menulis ke direktori [tergantung pada sistem yang dimaksud, terkadang Anda tidak perlu melakukan apapun, atau terkadang Anda perlu menyetel CHMOD 755 ke direktori, atau jika ada masalah dengan 755, Anda dapat mencoba 777, tetapi 777 tidak disarankan karena kurang aman].
Selanjutnya, agar CIDRAM dapat melindungi basis kode atau CMS Anda, Anda harus membuat "titik masuk". Titik masuk ini terdiri dari tiga hal:
- Menyertakan file "loader.php" pada titik yang sesuai dalam basis kode atau CMS Anda.
- Menginstansiasi CIDRAM core.
- Memanggil metode "protect".
Contoh sederhana: