Yapılandırma

Tüm yapılandırma ortam değişkenleriyle yapılır (yerelde .env, Docker’da konteyner ortamı). Depodaki .env.example tam seti belgeler; bu sayfa gerçekten değiştireceğiniz olanları açıklar.

QueryProxy ayarları

retry_after türetilir: DB_QUEUE_RETRY_AFTER’ı (ya da Beanstalkd / Redis karşılığını) kendiniz ayarlamadıkça QUERYPROXY_EXECUTION_TIMEOUT + 30 saniyedir (varsayılan 300 için 330). Docker girişi (entrypoint), işçinin --timeout (çalıştırma zaman aşımı + 10) ve stopwaitsecs (çalıştırma zaman aşımı + 20) değerlerini de aynı ayardan türetir. retry_after’ı açıkça ayarlarsanız çalıştırma zaman aşımının üzerinde tutun, çünkü sorgu job’u o noktada durdurulur; varsayılan +30 bir pay bırakır. Ona eşit ya da altındaki bir değer, yavaş bir sorgunun hâlâ çalışırken yeniden rezerve edilmesine ve sonra başarısız işaretlenmesine yol açar — yazması commit olabilse bile — ve queue:work (daemon ya da --once) veya queue:listen başlarken bir uyarı loglar. 0.2.0 .env.example’ından kalma sabit bir *_QUEUE_RETRY_AFTER=330 türetmeyi durdurur; bilerek ayarlamadıysanız kaldırın.

Kabul edilen bir QUERYPROXY_REQUIRE_2FA TOTP kodu yakılır, dolayısıyla penceresinin kalanında yeniden kullanılamaz. Pratik bir sonucu: aynı 30 saniyelik adımda ikinci bir cihazdan giriş yapmak için bir sonraki kodu beklemek gerekir.

QUERYPROXY_EXTRA_UNTRUSTED_LANGUAGES ve QUERYPROXY_EXTRA_DANGEROUS_VARIABLES, SQL korumalarının CREATE EXTENSION ve SET’i değerlendirdiği iki listeye ekleme yapar. Yalnızca genişletebilirler: yerleşik girdiler tabandır, ortamın verdiği her şeyin üstüne yeniden eklenir; dolayısıyla kısaltılmış bir liste guard’ı etkisiz kılamaz.

MySQL / MariaDB hedefleri: sql_mode

Guard tırnakları ve ters eğik çizgileri varsayılan biçimde okur; bu yüzden oturum sql_mode’u bunları farklı okuyacaksa talep reddedilir. QueryProxy, bir mysql ya da mariadb bağlantısında SQL’i çalıştırmadan önce @@SESSION.sql_mode değerini okur; NO_BACKSLASH_ESCAPES ya da ANSI_QUOTES içeriyorsa talep başarısız olur ve hiçbir şey çalışmaz; mesaj ilgili bayrağı adıyla belirtir. QueryProxy’nin kendisi bağlanırken, sunucunun varsayılanının yerine geçen katı bir sql_mode ayarlar; bu yüzden denetim tetiklenirse bağlandıktan sonra modu neyin değiştirdiğine bakın (aradaki bir vekil, değişmiş bir bağlantı ayarı). Bayrakları sunucu ve bağlantı kullanıcısı varsayılanlarından uzak tutmak yine de yerindedir, ama tek başına sorunu gidermez. sql_mode’u değiştiren bir SET göndermek her driver’da reddedilir (bkz. SQL korumaları).

Uygulama anahtarı ve HTTPS

APP_KEY, saklanan bağlantı kimlik bilgilerinizi ve chat sırlarınızı şifreler. Üretimde açıkça belirleyin ve sabit tutun — yeniden üretilen bir anahtar (ör. konteyner yeniden oluşturulunca) saklanan tüm kimlik bilgilerini okunamaz hale getirir. php artisan key:generate --show ile üretin ve döndürürken eski anahtarı APP_PREVIOUS_KEYS’e (virgülle ayrılmış) taşıyın ki mevcut şifreli veri hâlâ çözülebilsin.

HTTPS’i bir ters vekil arkasından sunarken SESSION_SECURE_COOKIE=true ayarlayın.

Ters vekil arkasında

Kırıcı değişiklik — QueryProxy’nin önünde bir vekil varsa TRUSTED_PROXIES’i ayarlayın. Önceki sürümler her vekile güveniyordu. Bu sürümden itibaren hiçbir vekile varsayılan olarak güvenilmez ve siz kendinizinkini yazana kadar uygulama bağlanan tarafı istemci olarak okur.

TRUSTED_PROXIES, X-Forwarded-* başlıklarını ayarlamasına izin verilen IP’lerin ya da CIDR’ların virgülle ayrılmış listesini alır:

TRUSTED_PROXIES=10.0.0.0/8

Bu liste vekilinizin adını içermedikçe X-Forwarded-Proto yok sayılır — HTTPS algılanmaz, dolayısıyla HSTS başlığı gönderilmez — ve denetim kayıtlarına istemcinin değil vekilin adresi düşer.

Asla * yazmayın. Her vekile güvenmek, herhangi bir istemcinin kendi X-Forwarded-For başlığını göndermesine izin verir; bu, denetim izindeki istemci IP’sini sahteler ve sınırsız giriş ile 2FA denemesi hakkı verir, çünkü iki throttle da IP başına anahtarlanır.

X-Forwarded-Host, listede ne yazarsa yazsın hiç dikkate alınmaz: sahte bir host başlığı parola sıfırlama e-postasındaki bağlantıyı yeniden yazıyordu. İkinci bir katman olarak istek host’u APP_URL’deki host’a (ve www. kardeşine) sabitlenir; böylece mutlak URL’ler — imzalı route’lar, parola sıfırlama e-postaları — her zaman kendi kurulumunuzu gösterir. APP_URL’i kullanıcıların gerçekten eriştiği adrese ayarlayın.

Kurulum birden fazla ada yanıt veriyorsa diğerlerini TRUSTED_HOSTS’e yazın:

TRUSTED_HOSTS=queryproxy.internal,db.example.com

X-Forwarded-Host yok sayıldığına göre çok alan adlı bir dağıtımı çalıştırmanın desteklenen yolu budur — listelemediğiniz bir hostname yine de bir parola sıfırlama bağlantısını yeniden yazamaz. Adlar APP_URL’deki host’a (ve www. kardeşine) eklenir, onun yerine geçmez. Hostname olarak okunamayan girdiler sessizce atılır, böylece bir yazım hatası kurulumu çökertemez.

İki değer de uygulama yapılandırması üzerinden okunur, bu yüzden .env’e yazmak yeterlidir. Yapılandırmayı cache’liyorsanız değiştirdikten sonra php artisan config:cache’i yeniden çalıştırın; Docker imajı her açılışta yeniden cache’ler.

Uygulama veritabanı

QueryProxy’nin kendi verisi (kullanıcılar, takımlar, talepler, denetim günlüğü) varsayılan olarak SQLite’ta yaşar — sıfır yapılandırma. MySQL veya PostgreSQL için standart Laravel değişkenlerini ayarlayın:

DB_CONNECTION=pgsql        # veya mysql
DB_HOST=db
DB_PORT=5432
DB_DATABASE=queryproxy
DB_USERNAME=queryproxy
DB_PASSWORD=degistir-beni

Bu, uygulama veritabanıdır — proxy’lediğiniz veritabanları arayüzde Connections altında, takım bazında ve şifreli kimlik bilgileriyle tanımlanır.

Kuyruk

Kuyruk varsayılan olarak veritabanı tabanlıdır (Redis gerekmez). Redis’e taşımak için:

QUEUE_CONNECTION=redis
REDIS_HOST=redis

REDIS_QUEUE_RETRY_AFTER isteğe bağlıdır: ayarlanmamışsa QUERYPROXY_EXECUTION_TIMEOUT + 30 saniyeden türetilir (bkz. ayar tablosunun altındaki not). Yalnızca bu değeri geçersiz kılmak için ayarlayın ve çalıştırma zaman aşımının üzerinde tutun.

İşçi komutu aynı kalır. --timeout değerini çalıştırma zaman aşımının biraz üzerinde tutun (çalıştırma zaman aşımı + 10 saniye; QUERYPROXY_EXECUTION_TIMEOUT varsayılan olarak 300’dür, dolayısıyla 310):

php artisan queue:work --queue=queries,default --tries=1 --timeout=310

Manuel kurulumda bu sayı sizin için türetilmez: QUERYPROXY_EXECUTION_TIMEOUT’u değiştirirseniz --timeout’u da ona göre değiştirin (Docker girişi bunu kendisi türetir).

Aynı uyarı (retry_after’ın çalıştırma zaman aşımına eşit ya da altında olması) yalnızca daemon queue:work için değil, queue:listen ya da queue:work --once başlarken de bir kez loglanır. queue:listen’ın başlattığı kısa ömürlü queue:work --once süreçleri bunu tekrarlamaz.

Deponun docker-compose.yml dosyasındaki ayrı worker örneği artık --timeout=310 değerini sabit yazmaz: imaj girişinin QUERYPROXY_EXECUTION_TIMEOUT + 10 olarak türettiği QUERYPROXY_WORKER_TIMEOUT’u geçirir. O servis için QUERYPROXY_EXECUTION_TIMEOUT’u ayarlayın, işçi onu izler. Bu, imajın varsayılan girişini gerektirir; bu yüzden worker servisinde entrypoint:’i geçersiz kılmayın.

S3 üzerinde sonuç depolama

QUERYPROXY_RESULT_DISK=s3 ve standart AWS_* değişkenlerini ayarlayın. Sonuç dosyaları NDJSON olarak, akış hâlinde yazılır — bellek kullanımı sonuç boyutundan bağımsız olarak sabit kalır.

Disk özel olmalıdır. Sonuç yolları tahmin edilebilirdir (results/{team_id}/{id}.ndjson); bu yüzden herkese açık sunulan bir disk, indirme yetkilendirmesini tümden atlayarak her takımın satırlarını doğrudan web kökünden dağıtırdı. Bu nedenle QUERYPROXY_RESULT_DISK public diskini ya da visibility => public ile yapılandırılmış herhangi bir diski gösteriyorsa QueryProxy sonuç yazmayı reddeder ve talep bunun yerine açık bir mesajla başarısız olur.

SQL Server hedefleri

Varsayılan Docker imajı pdo_pgsql, pdo_mysql ve pdo_sqlite ile gelir. Microsoft SQL Server veritabanlarını proxy’lemek için Dockerfile’ı Microsoft’un ODBC sürücüsü ve sqlsrv / pdo_sqlsrv PECL eklentileriyle genişletin, ardından queryproxy/queryproxy yerine kendi imajınızı derleyip çalıştırın. Onaylı sorgular işçide çalıştığı için eklentilerin hem web sürecini hem kuyruk işçisini çalıştıran PHP derlemesinde bulunması gerekir.