Kimlik Doğrulama ve Yetkilendirme

Mevcut Diller: en | + es | + fr | + ja | + ko | + tr

+ +

Kimlik Doğrulama istediğiniz kişileri teyid etme işlemidir. + Yetkilendirme ise kişilerin nereye gireceklerine ve hangi bilgiye + ulaşacaklarına müsaade edilmesi işlemidir.

+ +

Genel erişim denetimi için Erişim Denetimi + Nasıl belgesine bakınız.

İlgili modüller ve Yönergeler
Giriş
Ön gereksinimler
Çalışmaya Başlama
Birden çok kişiye izin vermek
Olası Sorunlar
Diğer parola depolama yöntemleri
Birden çok tedarikçi kullanmak
Yetkilendirmenin biraz ötesi
Kimlik Doğrulama Arabelleği
Daha fazla bilgi

Ayrıca bakınız:

Yorumlar

İlgili modüller ve Yönergeler

+ +

Kimlik Doğrulama ve yetkilendirme işlemi ile ilgili üç tür modül + vardır. Genellikle her bir gruptan en az bir modül seçeceksiniz.

+ +

Kimlik Doğrulama türü (bkz. AuthType yönergesi) +
- mod_auth_basic
- mod_auth_digest
+
Kimlik Doğrulayıcı (bkz. + AuthBasicProvider + ve AuthDigestProvider yönergeleri) +
- mod_authn_anon
- mod_authn_dbd
- mod_authn_dbm
- mod_authn_file
- mod_authnz_ldap
- mod_authn_socache
+
Yetkilendirme (bkz. + Require yönergesi) +
- mod_authnz_ldap
- mod_authz_dbd
- mod_authz_dbm
- mod_authz_groupfile
- mod_authz_host
- mod_authz_owner
- mod_authz_user
+

+ +

Bu modüllere ek olarak, mod_authn_core ve + mod_authz_core modülleri bulunur. Bu modüller + yetkilendirme modüllerinin çekirdeğini oluşturan temel yönergeleri + gerçekler.

+ +

mod_authnz_ldap modülü kimlik doğrulama ve + yetkilendirme işlemlerinin ikisini birden gerçekleştirir. + mod_authz_host modülü bu işlemleri sunucu adına, IP + adresine ve isteğin karekteristiğine bağlı olarak gerçekleştirir. + Ancak kimlik doğrulama sisteminin bir parçası değildir. + mod_access ile geriye uyumluluk için + mod_access_compat diye bir modül daha vardır.

+ +

Muhtemelen göz atmak isteyeceğiniz Erişim + Denetimi nasıl belgesi, sunucuya erişimlerin çeşitli yollarından + bahsetmektedir.

Giriş

Sitenizde sadece küçük bir grup insana hitap eden ya da hassas + bilgileriniz varsa, bu makaledeki teknikleri kullanarak dilediğiniz + kişilerin sadece dilediğiniz sayfaları görüntülemesini + sağlayabilirsiniz.

+ +

Bu makale sitenizin bazı parçalarını korumak için kullanacağınız + "standart" yolları içermektedir.

+ +

Bilginize:

Eğer bilgileriniz gerçekten gizliliğe ihtiyaç duyuyorsa kimlik + doğrulamasına ilaveten mod_ssl modülünü de + kullanabilirsiniz.

+ +

Ön gereksinimler

+ +

Bu makalede bahsi geçen yönergeler ya ana sunucu yapılandırma + dosyasında (genellikle <Directory> bölümünde) ya da dizin içi + yapılandırma dosyalarında (.htaccess dosyaları) + bulunmak zorundadır.

+ +

Eğer .htaccess dosyalarını kullanmayı + tasarlıyorsanız, kimlik doğrulama yönergelerine bu dosyaların içine + koymaya izin veren sunucu yapılandırmasına ihtiyacınız olacaktır. + Bunun için, dizin içi yapılandırma dosyalarının içine hangi + yönergelerin konacağını belirleyen AllowOverride yönergesi kullanılır.

+ +

Kimlik doğrulamadan sözettiğimize göre, aşağıda gösterilen + şekilde bir AllowOverride yönergesine ihtiyacınız olacaktır:

+ +

AllowOverride AuthConfig

+ + +

Yönergeleri doğrudan ana sunucunun yapılandırma dosyasına + koyacaksanız bu dosyaya yazma izniniz olmalıdır.

+ +

Bazı dosyaların nerede saklandığını bilmek için sunucunun dizin + yapısı hakkında biraz bilgi sahibi olmanız gerekmektedir. Bu çok da + zor olmamakla birlikte bu noktaya gelindiğinde konuyu + netleştireceğiz.

+ +

Ayrıca mod_authn_core ve + mod_authz_core modülleri ya httpd + çalıştırılabilirinin içinde derlenmiş olmalı ya da + httpd.conf yapılandırma dosyası ile yüklenmelidir. Bu + iki modül HTTP sunucusunda kimlik doğrulama ve yetkilendirme + kullanımı ve yapılandırması için büyük öneme sahip temel yönergeleri + ve işlevselliği sağlar.

+ +

Çalışmaya Başlama

Burada, sunucu üzerindeki bir dizini parolayla korumak için + gereken temel bilgiler verilecektir.

+ +

İlk olarak bir parola dosyası oluşturmalısınız. Bunu nasıl + yapacağınız, özellikle, seçtiğiniz kimlik doğrulayıcıya göre + değişiklik gösterir. Bunun üzerinde ileride daha fazla duracağız. + Başlangıç için parolaları bir metin dosyasında tutacağız.

+ +

Bu dosya belge kök dizini altında olmamalıdır. Böylece başkaları + parola dosyasını indiremezler. Örneğin belgeleriniz + /usr/local/apache/htdocs üzerinden sunuluyorsa parola + dosyanızı /usr/local/apache/passwd dizininde + tutabilirsiniz.

+ +

Dosyayı oluşturmak için Apache ile gelen + htpasswd uygulamasını kullanacağız. Bu uygulama + Apache'nin kurulumunda belirtilen bin dizininde + bulunur. Eğer Apache'yi üçüncü parti paketlerden kurduysanız, + çalıştırılabilir dosyaların bulunduğu yollar üzerinde olmalıdır.

+ +

Bir dosya oluşturmak için şunları yazın:

+ +

+ htpasswd -c /usr/local/apache/passwd/passwords umut +

+ +

htpasswd size parola soracaktır arkasından da + teyit etmek için parolayı tekrar girmenizi isteyecektir:

+ +

+ # htpasswd -c /usr/local/apache/passwd/passwords umut + New password: parolam + Re-type new password: parolam + Adding password for user umut +

+ +

Eğer htpasswd normal yollar üzerinde değilse + çalıştırmak için dosyanın bulunduğu tam yeri belirtmeniz + gerekecektir. Dosyanın öntanımlı kurulum yeri: + /usr/local/apache2/bin/htpasswd

+ +

Bundan sonra, sunucuyu, parola sorması için ve kimlerin erişim + izni olacağını belirlemek için yapılandıracaksınız. Bu işlemi + httpd.confdosyasını düzenleyerek ya da bir + .htaccess dosyası kullanarak yapabilirsiniz. Örneğin, + /usr/local/apache/htdocs/secret dizinini korumayı + amaçlıyorsanız, şu yönergeleri kullanabilirsiniz. Bu yönergeleri + /usr/local/apache/htdocs/secret/.htaccess dosyası içine + veya httpd.conf içindeki <Directory + "/usr/local/apache/htdocs/secret"> bölümüne koyabilirsiniz.

+ +

AuthType Basic
+AuthName "Gizli Dosyalar"
+# (Aşağıdaki satırın kullanımı isteğe bağlıdır)
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+Require user umut

+ + +

Bu yönergeleri tek tek inceleyelim. + AuthType yönergesi + kullanıcının kimliğini doğrulamakta kullanılacak yöntemi seçer. En + çok kullanılan yöntem Basic'tir ve bu yöntem + mod_auth_basic modülüyle gerçeklenmiştir. Temel + (Basic) kimlik doğrulamasıyla gönderilen parolanın + şifrelenmeyeceğini unutmayın. Bu yöntem, bu sebepten dolayı + mod_ssl eşliğinde kullanılmadığı sürece yüksek + hassasiyete sahip bilgiler için kullanılmamalıdır. Apache bir başka + kimlik doğrulama yöntemini daha destekler: AuthType + Digest. Bu yöntem mod_auth_digest tarafından + gerçeklenmişti ve çok daha güvenli olacağı düşünülmüştü. Bu artık + geçerliliğini yitirdiğinden bağlantının bundan böyle + mod_ssl ile şifrelenmesi gerekmektedir.

+ +

AuthName yönergesi + ile kimlik doğrulamada kullanılacak Saha da + belirtilebilir. Saha kullanımının, başlıca iki işlevi vardır. + Birincisi, istemci sıklıkla bu bilgiyi kullanıcıya parola diyalog + kutusunun bir parçası olarak sunar. İkincisi, belirtilen kimlik + doğrulamalı alan için gönderilecek parolayı belirlerken istemci + tarafından kullanılır.

+ +

Örneğin, bir istemcinin "Gizli Dosyalar" alanında + kimliği doğrulanmış olsun. Aynı sunucu üzerinde "Gizli + Dosyalar" Sahası olarak belirlenmiş alanlarda aynı parola + özdevinimli olarak yinelenecektir. Böylece parola bir kere girilerek + aynı Sahayı paylaşan çok sayıda kısıtlanmış alana ulaşırken oluşacak + gecikmeden kullanıcı korunmuş olur. Güvenlik gerekçelerinden dolayı, + her sunucu adı değiştirilişinde istemcinin parolayı yeniden sorması + gerekir.

+ +

AuthBasicProvider + yönergesinin öntanımlı değeri file olduğundan, bu + durumda, bu yönergenin kullanımı isteğe bağlıdır. Ancak, eğer kimlik + doğrulaması için mod_authn_dbm ya da + mod_authn_dbd gibi farklı bir kaynak seçecekseniz + bu yönergeyi kullanmanız gerekecektir.

+ +

AuthUserFile + yönergesi htpasswd ile oluşturduğumuz parola + dosyasının yerini belirtmek için kullanılır. Eğer çok sayıda + kullanıcınız varsa her bir kullanıcıyı her kimlik doğrulama isteği + için kimlik bilgilerini bir metin dosyasında aramak gayet yavaş + olacaktır. Apache, kullanıcı bilgilerini hızlı bir veritabanı + dosyasında depolama özelliğine de sahiptir. Bu amaçla, + mod_authn_dbm modülünün + AuthDBMUserFile + yönergesi kullanılabilir. Bu dosyalar dbmmanage ve + htdbm programı ile oluşturulabilir ve değiştirilebilir. + Üçüncü parti modüllerinde çok sayıda + başka kimlik doğrulama türü de vardır.

+ +

Son olarak Require + yönergesi, sunucunun bu bölgesine erişimine izin verilen + kullanıcıları ayarlama işleminin kimlik doğrulamasıyla ilgili + kısmını sağlar. Bir sonraki bölümde Require yönergesini kullanmanın + çeşitli yoları üzerinde duracağız.

Birden çok kişiye izin vermek

+ +

Yukarıdaki yönergelerle bir dizinde sadece bir kişiye + (umut adlı kullanıcıya) izin verir. Çoğunlukla birden + çok kişiye izin verilmesi istenir. Bu durumda AuthGroupFile yönergesi + devreye girer.

+ +

Eğer birden çok kişiye izin vermek istiyorsanız içinde kullanıcı + isimlerinin olduğu bir grup dosyası oluşturmalısınız. Bu dosyanın + biçemi gayet basittir ve bunu herhangi bir metin düzenleyici ile + oluşturabilirsiniz. Bu dosyanın içeriği aşağıdaki gibi + görünecektir:

+ +

+ GroupName: umut samet engin kubilay +

+ +

Dosya, sadece, boşluklarla birbirinden ayrılmış gurup üyelerinin + isimlerinden oluşan uzun bir liste içerir.

+ +

Varolan parola dosyasına bir kullanıcı eklemek için şunu + yazın:

+ +

+ htpasswd /usr/local/apache/passwd/passwords birey +

+ +

Evvelce almış olduğunuz yanıtı yine alacaksınız ama bu sefer yeni + bir dosya oluşturulmak yerine var olan bir dosyaya eklenecektir. + (Yeni bir parola dosyası oluşturmak için -c seçeneği + kullanılır).

+ +

Şimdi, .htaccess dosyanızı veya + <Directory> bölümünüzü + aşağıda görüldüğü şekilde değiştirebilirsiniz:

+ +

AuthType Basic
+AuthName "Davete Binaen"
+# Satır isteğe bağlıdır:
+AuthBasicProvider file
+AuthUserFile "/usr/local/apache/passwd/passwords"
+AuthGroupFile "/usr/local/apache/passwd/groups"
+Require group Grupismi

+ + +

Artık, Grupismi gurubunda listelenmiş ve + password dosyasında kaydı olan kişiye, parolayı doğru + yazdığı takdirde izin verilecektir.

+ +

Çoklu kullanıcıya izin veren biraz daha az kullanılan başka bir + yol daha mevcuttur. Bir gurup dosyası oluşturmaktansa, şu yönergeyi + kullanabilirsiniz:

+ +

Require valid-user

+ + +

Require user umut satırı ile parola dosyasında + listelenmiş ve parolayı doğru olarak giren herhangi bir kişiye izin + vermektense, her grup için ayrı bir parola dosyası tutarak grup + davranışını taklit edebilirsiniz.

+ +

Olası Sorunlar

Temel kimlik doğrulama yolu belirtildiği için, sunucuya + yaptığınız her belge istediğinde kullanıcı adınızın ve parolanızın + doğrulanması gerekir. Hatta aynı sayfayı yeniden yüklerken ya da + sayfadaki her bir resim için bu yapılmalıdır (şayet korunmakta olan + bir dizinden geliyorsa). Bu işlem hızı azaltacaktır. Yavaşlama + miktarı parola dosyanızın büyüklüğü ile orantılı olacaktır, çünkü bu + işlem sırasında dosya açılacak ve kullanıcıların arasında isminiz + bulunana kadar liste aşağı doğru taranacaktır. Bu işlem sayfa her + yüklenişinde tekrar edilecektir.

+ +

Buradan çıkacak sonuç, bir parola dosyasına konulan kullanıcı + sayısında bir üst sınır olması gerekliliğidir. Bu sınır sunucunuzun + başarımına bağlı olarak değişiklik gösterir. Bir kaç yüz kayıtın + üstünde giriş yaptığınızda hız düşüşünü gözlemlebilirsiniz İşte bu + anda kimlik doğrulama için başka bir yöntem aramaya başlarsınız.

+ +

Diğer parola depolama yöntemleri

+ +

Parolaları basit bir metin dosyasında depolamak yukarıda + bahsedilen sorunlara yol açtığından parolaları başka bir yerde + depolamayı düşünebilirsiniz; örneğin bir veritabanında.

+ +

mod_authn_dbm ve mod_authn_dbd + modülleri bunu mümkün kılan iki modüldür. Depolama yönemi olarak + AuthBasicProvider file yerine, dbm + veya dbd kullanabilirsiniz.

+ +

Bir metin dosyası yerine bir dbm dosyası kullanım örneği:

+ +

<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider dbm
+    AuthDBMUserFile "/www/passwords/passwd.dbm"
+    Require valid-user
+</Directory>

+ + +

Başka seçenekler de mümkündür. Ayrınılar için + mod_authn_dbm belgesine başvurun.

+ +

Birden çok tedarikçi kullanmak

+ +

Kimlik doğrulama ve yetkilendirme mimarisine dayalı yeni + tedarikçiyi kullanarak tek bir yetkilendirme ya da kimlik doğrulama + yöntemine kilitlenip kalmayacaksınız. Aslında birden çok tedarikçi + ihtiyacınıza cevap vermek için bir arada kullanılabilir. Aşağıdaki + örnekte dosya ve LDAP tabanlı kimlik doğrulama tedarikçileri bir + arada kullanılmıştır.

+ +

<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file ldap
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    Require valid-user
+</Directory>

+ + +

Bu örnekte dosya tedarikçisi, ilk olarak kullanıcının kimliğini + doğrulamaya teşebbüs edecektir. Kullanıcının kimliği + doğrulanamıyorsa LDAP tedarikçisi çağırılır. Eğer kurumunuz birden + çok kimlik doğrulama tedarikçisini yürürlüğe koyuyorsa bu, kimlik + doğrulama faaliyet alanının genişletilmesini sağlar. Diğer kimlik + kanıtlama ve yetkilendirme senaryoları tek bir kimlik doğrulaması + ile birden fazla yetkilendirme türüne izin verebilir.

+ +

Çok sayıda kimlik doğrulama tedarikçisi uygulamaya konulabileceği + gibi, çok sayıda yetkilendirme yöntemi de kullanılabilir. Bu örnekte + dosya için hem dosyalı hem de LDAP grup kimlik doğrulaması + kullanılmıştır.

+ +

<Directory "/www/docs/private">
+    AuthName "Private"
+    AuthType Basic
+    AuthBasicProvider file
+    AuthUserFile "/usr/local/apache/passwd/passwords"
+    AuthLDAPURL ldap://ldaphost/o=yourorg
+    AuthGroupFile "/usr/local/apache/passwd/groups"
+    Require group GroupName
+    Require ldap-group cn=mygroup,o=yourorg
+</Directory>

+ + +

Kimlik doğrulama konusunu biraz daha genişletirsek, <RequireAll> ve + <RequireAny> gibi yetkilendirme taşıyıcısı + yönergelerle hangi iznin hangi sırayla uygulanacağını + belirlenebilir. Yetkilendirme Taşıyıcıları bölümünde bunun bir uygulama + örneğini görebilirsiniz.

+ +

Yetkilendirmenin biraz ötesi

Tek bir veri deposundan yapılacak tek bir sınamadan çok daha + esnek kimlik doğrulaması yapılabilir. Sıralama, mantık ve hangi + kimlik doğrulamasının kullanılacağını seçmek mümkündür.

+ +

Mantık ve sıralamanın uygulanması

+ +

Yetkilendirmenin hangi sırayla uygulanacağı ve nasıl + denetleneceği geçmişte biraz gizemli bir konuydu. Apache 2.2'de, + tedarikçi tabanlı kimlik doğrulamasının devreye girmesiyle asıl + kimlik doğrulama işlemini yetkilendirme ve destek işlevselliğinden + ayırmak mümkün oldu. Bunun faydalarından birisi de kimlik + doğrulama tedarikçilerinin yapılandırılabilmesi ve auth modülünün + kendi yükleme sırasından bağımsız olarak özel bir sırayla + çağrılabilmesidir. Bu tedarikçi tabanlı mekanizmanın aynısı + yetkilendirmeye de getirilmiştir. Bunun anlamı Require yönergesinde hangi + izin yönteminin kullanılması gerektiğinin belirtmesinin yanında + hangi sırayla çağırılacaklarının da belirlenebildiğidir. Çok + sayıda yetkilendirme yöntemi kullanıldığında, bunlar, Require yönergelerinin + yapılandırma dosyasında göründükleri sıra ile çağırılır.

+ +

<RequireAll> ve <RequireAny> gibi yetkilendirme + taşıyıcısı yönergelerin devreye girmesiyle yetkilendirme + yöntemlerinin ne zaman çağırılacağı ve çağırıldığında ve erişime + izin verirken hangi kuralların uygulanacağı konusunda denetim + yapılandırmanın eline geçmektedir. Karmaşık yetkilendime mantığını + ifade etmek için kullanılan bir örneği görmek için + Yetkilendirme + Taşıyıcıları bölümüne bakınız.

+ +

Öntanımlı olarak tüm + Require yönergeleri, <RequireAny> + taşıyıcı yönergesinin içine konur. Başka bir deyişle eğer + belirtilen kimlik doğrulama yöntemlerinden herhangi biri başarılı + olursa yetkilendirme de sağlanmış olur.

+ + + +

Erişim denetimi için yetkilendirme tedarikçilerinin + kullanımı

+ +

Kullanıcı adı ve parolasına göre kimlik doğrulama hikayenin + sadece bir bölümüdür. Sıklıkla insanlara kim olduklarına göre + değil birşeylere dayanarak izin vermek istersiniz. Örneğin nereden + geldikleri gibi.

+ +

all, env, host ve + ip gibi yetkilendirme tedarikçileri ile, bir belgenin + istendiği makinenin IP adresi veya konak ismi gibi bazı özelliklerine + dayalı olarak erişime izin verip vermeyeceğinizi belirtebilirsiniz.

+ +

Bu tedarikçilerin kullanımı Require yönergesinde açıklanmıştır. Bu yönergeler, + isteklerin işlenmesi sırasında yetkilendirme aşamasında + çağırılacak yetkilendirme tedarikçilerini kayda geçirir. Örneğin: +

+ +

Require ip adres
+

+ + +

Burada, adres bir IP adresidir (veya kısmi bir IP + addresidir)

+ +

Require host alan_adı
+

+ + +

Burada, alan_adı bir tam nitelikli alan adıdır + (ya da kısmi alan adıdır); gerekirse çok sayıda alan adı veya IP + adresi de belirtilebilir.

+ +

Örneğin, yorum alanını gereksiz iletilerle dolduran birini uzak + tutmak istediğinizi varsayalım. Bu kişiyi uzak tutmak için şunları + yapabilirsiniz:

+ +

<RequireAll>
+    Require all granted
+    Require not ip 10.252.46.165
+</RequireAll>

+ + +

Bu adresden gelen ziyaretçiler bu yönergedeki içeriği + göremeyeceklerdir. Bunun yerine, elinizde IP adresi değil de + makine adı varsa şunu kullanabilirsiniz:

+ +

<RequireAll>
+    Require all granted
+    Require not host host.example.com
+</RequireAll>

+ + +

Eğer alan adının tamanıdan gelecek olan bütün erişimleri + engellemek isterseniz adresin ya da alan adının bir parçasını + belirtin:

+ +

<RequireAll>
+    Require all granted
+    Require not ip 192.168.205
+    Require not host phishers.example.com moreidiots.example
+    Require not host ke
+</RequireAll>

+ + +

<RequireAll> yönergesini çok sayıda + <Require> yönergesi ile birlikte kullanarak, + sadece not ile olumsuzlanan tüm koşulları gerçekleyen + bağlantılara erişim verilir. Başka bir deyişle, olumsuzlanan koşulları + gerçeklemeyen bağlantıların erişimi engellenir.

+ + + +

Erişim denetimi ve geriye uyumluluk

+ +

Kimlik doğrulama için tedarik tabanlı mekanizma kullanımının + yan etkilerinden birisi, + Order, + Allow, + Deny ve + Satisfy erişim + denetim yönergelerine artık ihtiyaç duyulmamasıdır. Ancak eski + yapılandırmalarla uyumluluğu sağlamak için bu yönergeler + mod_access_compat modülüne taşınmıştır.

+ +

Note

mod_access_compat ile sağlanan yönergelerin + kullanımı artık önerilmemekte, mod_authz_host + modülündeki yönergeler önerilmektedir. Order, Allow veya Deny ile + Require gibi daha yeni + olanlarının yenilerle karışık kullanımı teknik olarak mümkünse de + önerilmemektedir. mod_access_compat modülü, 2.4 + yükseltmesini kolaylaştırmak için sadece eski yönergeleri içeren + yapılandırmaları desteklemek üzere oluşturulmuştur. Daha ayrıntılı + bilgi için yükseltme belgesine bakınız. +

+ + +

Kimlik Doğrulama Arabelleği

Zaman zaman kimlik doğrulama ağınızda veya sağlayıcı(ları)nızda kabul + edilemez yükler oluşturur. Bu çoğunlukla mod_authn_dbd + (veya üçüncü parti/özel sağlayıcıların) kullanıcılarını etkiler. Bununla + ilgilenmek için httpd 2.3/2.4, kimlik bilgilerini arabelleklemek ve özgün + sağlayıcıların yüklerini azaltmak için yeni bir arabellekleme sağlayıcısı + olarak mod_authn_socache modülü ile gelmektedir.

Bu, bazı kullanıcılar için önemli bir başarım artışı sağlayabilir.

Daha fazla bilgi

Daha fazla bilgi için mod_auth_basic ve + mod_authz_host modüllerinin belgelerine bakınız. + AuthnProviderAlias + yönergesi ile bazı yapılandırmalarınızı basitleştirebilirsiniz.

+ +

Apache tarafından desteklenen şifrelerle ilgili bilgi için Parola Biçemleri + belgesine bakınız.

+ +

Erişim Denetimi nasıl belgesinden de + bazı bilgiler edinebilirsiniz.