Access Server diskte düzenlediğiniz post_auth betiğini yok sayıyor

Hiçbir şeyi değiştirmeyen düzenlenmiş bir mac.py olağan ilk belirtidir. Diskteki dosya Access Server belirliğinin yürüttüğü şey değildir; kimlik doğrulama hizmeti betiği sunucunun yapılandırma veritabanından yükler ve oturum açmayı tam olarak o saklanan kopya belirler. Saklanan değer değiştirilene kadar her test yalnızca eski betiğin hâlâ çalıştığını kanıtlar.

İşi üç koşul belirler: değerin hiç yapılandırma veritabanına konup konmadığı, hizmete yeniden yükleme emrinin verilip verilmediği ve değiştirdiğiniz kodun gerçekten her bağlantıda çalışıp çalışmadığı. Her birinin belirtisi farklıdır ve yanlış olanı düzeltmek bir bakım penceresini boşa harcar.

Dosya bir kaynaktır, çalışan kopya değil

Access Server post-auth betiğini auth.module.post_auth_script anahtarı altında tutar. Dosyayı düzenlemek yalnızca çalışma kopyanızı günceller. Daemon saklanan değeri okur, bu yüzden değişiklik eski kaydı silip yeni dosyayı yerine koyana kadar görünmez kalır. O saklanan değer, kimlik doğrulama hizmetinin baktığı tek kopyadır.

Değiştirmeden önce okuyun. Düzenlediğiniz dosyayla zaten eşleşiyorsa sorun depolamada değildir ve kapsam sorusuna geçin. Daha eski bir sürüm gösteriyorsa değişiklik hizmete hiç ulaşmamıştır.

./sacli -k auth.module.post_auth_script ConfigGet

Saklanan kopyayı değiştirin, sonra uygulayın

Yazmadan önce silmek süs değildir. ConfigPut ile --value_file değeri tek adımda değiştirir ve önce ConfigDel yapmak eski veya bozuk bir kaydın kalmasını olanaksız kılar. Başlamadan önce çalışan betiğin bir kopyasını betik dizininin dışında tutun.

./sacli -k auth.module.post_auth_script ConfigDel
# store the file, then apply it
./sacli -k auth.module.post_auth_script --value_file=/root/post_auth.py ConfigPut
./sacli start

sacli start değişen yapılandırmayı iç hizmetlere uygular ve yeni betiği yürürlüğe koyan şey budur. Bu, tüm makineyi veya daemonu yeniden başlatmakla aynı değildir ve değişikliğiniz bunu gerektirmedikçe onunla değiştirilmemelidir.

Değer dosyası için mutlak bir yol kullanın ve rootun onu okuyabildiğini doğrulayın. Kabuğunuzdan çözülen ama hizmet hesabından çözülmeyen bir yol, ConfigGet içinde doğru görünen ve ilk oturum açmada başarısız olan bir saklanan değer üretir. Saklanan sonucu sacli start sonrasında bir kez daha kontrol edin, öncesinde değil.

Modül kapsamı mı bağlantı başına mı: sorgu nereye ait

Python modül düzeyindeki deyimleri betik yüklendiğinde bir kez çalıştırır. Bu yüzden dosyanın başına yazılan bir veritabanı sorgusu tabloyu yükleme sırasında okur ve bu yanıtı sonraki her bağlantı için saklar. Bir değişikliğin hiçbir şey yapmıyor gibi görünmesinin ikinci nedeni budur: kod çalışır, ama beklediğiniz anda değil.

Sorguyu post_auth işleyicisinin içine koyun ki her kimlik doğrulamada çalışsın. Belgelenmiş imzayı koruyun, işleyicinin aldığı kimlik doğrulama sonucunu ayarlayın ve çıplak bir sayı yerine aynı nesneyi döndürün.

Bağlantı işlemeyi de işleyicinin içinde tutun. İçe aktarma sırasında açılan bir bağlantı, ilk kullanıcı oturum açmadan önce sunucu tarafından kapatılabilir ve ortaya çıkan hata bozuk bir betikten çok reddedilmiş kimlik bilgisi gibi görünür.

İki ret yolu, tek sahip

Karar yerel bir sorguysa sonucun sahibi Python işleyicisidir. Dış bir HTTP denetimiyse yanıtı komutun çıkış durumu taşısın: sıfır olmayan kodla çıkan bir sarmalayıcı oturum açmayı reddeder ve son komutun durumu açık bir exit olmadan betiğin durumu olur.

Sırrı süreç listesinin dışında tutun. root tarafından okunabilen bir dosya veya hizmetin ilettiği bir ortam değeri, herhangi bir yerel kullanıcının ps üzerinden okuyabileceği bir argümandan daha güvenlidir. Uç noktayı çağrıdan önce bir değişkene sabitleyin, böylece yazım hatası yapılandırma sırasında başarısız olsun, birinin oturum açması sırasında değil. Bu sırrı diğer tüm kimlik bilgileri gibi döndürün.

Her denetim için tek sahip seçin. Veritabanını sorgulayan ve aynı zamanda bir HTTP hizmetini çağıran betik, ikisinin ayrıştığı durum için ilan edilmiş bir öncelik kuralına ihtiyaç duyar, yoksa günlükteki ret nedeni kullanıcıya söylenenle örtüşmez.

Yöneticiyi kilitlemeden uygulayın

İki önlem değişikliği geri alınabilir kılar: betiğe bağlı olmayan ikinci bir yönetici hesabı ve betik dizininin dışında tutulan bilinen iyi bir kopya. Değişikliği bir bakım penceresinde uygulayın, sonra bağlantıyı kesmeden önce bir deneme oturumu ve bir kasıtlı reddi izleyin. Günlük kimlik doğrulama kararı yerine sözdizimi hatası gösteriyorsa saklanan betik bozuktur ve her oturum açma başarısız olur.

İki koşul bekleyin der: değer dosyasını root olarak okuyamıyorsunuz ya da yönetim arayüzüne ikinci bir yolunuz yok. İkisi de küçük bir değişikliği kilitlemeye dönüştürür ve hiçbiri günün sonunda bir üretim sunucusunda denenmeye değmez. Access Server belgeleri post-auth arayüzünü ve desteklediği alanları kapsar.