repo_zf1/documentation/manual/pl/module_specs/Zend_Acl-Advanced.xml

<?xml version="1.0" encoding="UTF-8"?>
<!-- Reviewed: no -->
<sect1 id="zend.acl.advanced">

    <title>Zaawansowane użycie</title>

    <sect2 id="zend.acl.advanced.storing">

        <title>Trwałe przechowywanie danych ACL</title>

        <para>
            Klasa <classname>Zend_Acl</classname> została zaprojektowana w taki 
            sposób, aby nie wymagała żadnej szczególnej technologii backendu do 
            przechowywania danych <acronym>ACL</acronym> takiej jak np. baza 
            danych czy serwer buforujący. Kompletna implementacja w 
            <acronym>PHP</acronym> pozwala na podstawie <acronym>Zend_Acl</acronym> 
            budować dostosowane narzędzia administracyjne, które są relatywnie łatwe 
            oraz elastyczne. Wiele sytuacji wymaga pewnej formy interaktywnego 
            zarządzania <acronym>ACL</acronym>, a <classname>Zend_Acl</classname> 
            zapewnia metody do ustawiania oraz odpytywania kontroli dostępu aplikacji.
        </para>

        <para>
            Przechowywanie danych <acronym>ACL</acronym> jest zadaniem pozostawionym 
            dla programisty, dlatego, że przykłady użycia mogą się bardzo różnić w rozmaitych
            sytuacjach. Ponieważ możliwe jest serializowanie <classname>Zend_Acl</classname>, 
            obiekty <acronym>ACL</acronym> mogą być serializowane za pomocą funkcji 
            <acronym>PHP</acronym> <ulink url="http://php.net/serialize"><methodname>serialize()</methodname></ulink>,
            a wyniki mogą być przechowane tam gdzie określi to programista, na
            przykład w pliku, w bazie danych lub w mechanizmie buforowania.
        </para>

    </sect2>

    <sect2 id="zend.acl.advanced.assertions">

        <title>Tworzenie warunkowych reguł ACL z zapewnieniami</title>

        <para>
            Czasem reguła przyznawania lub zabraniania dostępu roli do zasobu nie
            powinna być absolutna, ale powinna być oparta na różnych kryteriach.
            Na przykład załóżmy, że pewien dostęp powinien być przyznany, ale
            jedynie między godziną 8:00 a 17:00. Innym przykładem może być zabranie
            dostępu adresom IP, które zostały oznaczone jako źródło nadużyć.
            <classname>Zend_Acl</classname> ma wbudowaną obsługę implementowania 
            reguł opartych na dowolnych warunkach, wedle potrzeb programisty.
        </para>

        <para>
            <classname>Zend_Acl</classname> zapewnia obsługę warunkowych reguł za 
            pomocą interfejsu <classname>Zend_Acl_Assert_Interface</classname>. 
            W celu użycia interfejsu zapewnień reguł, programista pisze klasę, 
            ktora implementuje metodę <methodname>assert()</methodname> interfejsu:
        </para>

        <programlisting language="php"><![CDATA[
class CleanIPAssertion implements Zend_Acl_Assert_Interface
{
    public function assert(Zend_Acl $acl,
                           Zend_Acl_Role_Interface $role = null,
                           Zend_Acl_Resource_Interface $resource = null,
                           $privilege = null)
    {
        return $this->_isCleanIP($_SERVER['REMOTE_ADDR']);
    }

    protected function _isCleanIP($ip)
    {
        // ...
    }
}
]]></programlisting>

        <para>
            Kiedy klasa zapewnień jest już dostępna, programista musi przekazać
            klasę zapewnień kiedy przypisuje regułę warunkową. Reguła, która jest
            utworzona z klasą zapewnienia będzie jedynie stosowana wtedy, gdy metoda
            zapewnienia zwróci logiczną wartośc <constant>TRUE</constant>.
        </para>

        <programlisting language="php"><![CDATA[
$acl = new Zend_Acl();
$acl->allow(null, null, null, new CleanIPAssertion());
]]></programlisting>

        <para>
            Powyższy kod tworzy warunkową regułę dostępu, ktora pozwala na dostęp
            do wszystkich przywilejów do wszystkich zasobów dla wszystkich ról, z
            wyjątkiem adresów IP, będących na czarnej liście. Jeśli żądanie pochodzi
            z adresu IP, który nie jest uznany jako "czysty", wtedy reguła nie ma
            zastosowania. Z tego względu, że reguła ma zastosowanie do wszystkich
            ról, zasobów oraz przywilejów, zablokowany adres IP będzie miał
            zabroniony cały dostęp. Jest to specjalny przypadek i powinien być
            zrozumiany tak, że we  wszystkich innych przypadkach (np., tam gdzie
            specyficzna rola, zasób lub przywilej są określone w regule), nieudane
            zapewnienie spowoduje, że reguła nie zostanie zastosowana i inne reguły
            powinny być zastosowane aby określić czy dostęp jest dozwolony czy
            zabroniony.
        </para>

        <para>
            Metoda <methodname>assert()</methodname> obiektu zapewnienia jest przekazywana do
            ACL, roli, zasobu, oraz przywileju do których stosuje się zapytanie
            autoryzacyjne (np., <methodname>isAllowed()</methodname>), w celu dostarczenia
            kontekstu dla klasy zapewnienia aby określić warunki zapewnienia tam
            gdzie są one potrzebne.
        </para>

    </sect2>

</sect1>