2026'da Symfony Guvenlik Sistemi: Voter'lar, Firewall'lar ve Teknik Mulakat Sorulari

Symfony Security bileseni, 2026 yilinda backend gelistiricileri icin yapilan teknik mulakatlarda en sik sorgulanan ve en kapsamli degerlendirilen konularin basinda gelmektedir. Kimlik dogrulama, yetkilendirme, firewall'lar, voter'lar — her katman, senior profilleri orta seviye gelistiricilerden ayiran hassas soyutlamalar uzerine insa edilmistir. Symfony 7.4 LTS ile birlikte guvenlik sistemi, erisim kararlarina iliskin hata ayiklamanin dogrudan Twig uzerinden yapilabilmesini saglayarak gozlemlenebilirlik kazanirken, framework'un gucunu olusturan genisletilebilir mimariyi korumaya devam etmektedir.

Bu makale, Symfony guvenlik sisteminin ic isleyisini derinlemesine incelemektedir: firewall yapilandirmasi, erisim token yonetimi, voter tasarimi, karar stratejileri ve guvenlik guclendirme en iyi uygulamalari. Her kavram, uretime hazir kodlarla orneklenmis ve teknik mulakatlarda sorulan sorularla iliskilendirilmistir.

Firewall'lar: ilk savunma hatti

Symfony guvenlik sistemi, security.yaml dosyasinda tanimlanan firewall mimarisi uzerine kuruludur. Her firewall, kendi kimlik dogrulama ve erisim kontrolu kurallarina sahip belirli bir rota kumesi icin bir koruma cevresi tanimlar. Tanim sirasi belirleyicidir: Symfony firewall'lari sirasiyla tarar ve URL'ye uyan ilk firewall'u uygular.

# config/packages/security.yaml
security:
    firewalls:
        dev:
            pattern: ^/(_(profiler|wdt))/
            security: false

        api:
            pattern: ^/api/
            stateless: true
            custom_authenticators:
                - App\Security\ApiTokenHandler

        main:
            lazy: true
            provider: app_user_provider
            form_login:
                login_path: app_login
                check_path: app_login
            logout:
                path: app_logout

    access_control:
        - { path: ^/api/public, roles: PUBLIC_ACCESS }
        - { path: ^/api/, roles: ROLE_API_USER }
        - { path: ^/admin, roles: ROLE_ADMIN }
        - { path: ^/dashboard, roles: ROLE_USER }

Bu yapilandirmada uc firewall bir arada bulunmaktadir. dev firewall'u, Profiler ve Web Debug Toolbar rotalari icin guvenlik sistemini tamamen devre disi birakarak gelistirme ortaminda herhangi bir mudahaleyi onlemektedir. api firewall'u, API endpoint'lerini ozel token tabanli durum bilgisiz (stateless) kimlik dogrulama ile korumaktadir. main firewall'u, web arayuzu icin oturum tabanli klasik form kimlik dogrulamasini yonetmektedir.

access_control bolumu, kimlik dogrulamadan sonra degerlendirilen genel erisim kurallarini tanimlar. Kural sirasi kritiktir: ilk eslesen kural kazanir. /api/public uzerindeki PUBLIC_ACCESS kurali, api firewall'u aktif olsa bile kimlik dogrulamasi gerektirmeden erisime izin verir. Bu incelik, mulakatlarda sikca sorulan bir konudur.

Stateless ve Stateful: iki kimlik dogrulama paradigmasi

Stateless ve stateful kimlik dogrulama arasindaki tercih, uygulamanin guvenlik mimarisini belirler. Stateful paradigmada (main firewall'u) Symfony, kimlik dogrulama tokenini PHP oturumunda saklar. Sonraki her istek, guvenlik baglamini oturumdan yeniden olusturur ve yeniden kimlik dogrulama gerektirmez. lazy: true bayraqi, bu sureci optimize ederek oturumu yalnizca yetkilendirme dogrulamasi fiilen gerektiginde yukler.

Stateless paradigmada (api firewall'u) her istek kendi kimlik bilgilerini tasir — Bearer token, API anahtari, JWT imzasi. Sunucu tarafinda hicbir oturum olusturulmaz. Bu model, dagitik mimariler, mikroservisler ve mobil istemciler icin dogal olarak uygundur, ancak her istegin kimlik dogrulama acisindan kendi kendine yeterli olmasini gerektirir.

Bu iki paradigma arasindaki tercih, teknik bir tercihe degil mimari bir kisitlamaya dayanir. Web arayuzune sahip monolitik bir uygulama, yonetim kolayligi nedeniyle stateful modu tercih eder. Heterojen istemciler tarafindan tuketilen bir API, yatay olceklenebilirlik icin stateless modu zorunlu kilar.

Access Token Handler: ozel kimlik dogrulama

Symfony 6.2, net bir arayuz araciligiyla kimlik dogrulama token yonetimini birlestiren Access Token Handler sistemini tanitti. Bu mekanizma, eski Guard Authenticator'larin yerini alarak Security bileseniyle daha dogrudan bir entegrasyon sunmaktadir.

namespace App\Security;

use App\Repository\ApiTokenRepository;
use Symfony\Component\Security\Core\Exception\BadCredentialsException;
use Symfony\Component\Security\Http\AccessToken\AccessTokenHandlerInterface;
use Symfony\Component\Security\Http\Authenticator\Passport\Badge\UserBadge;

final readonly class ApiTokenHandler implements AccessTokenHandlerInterface
{
    public function __construct(
        private ApiTokenRepository $repository,
    ) {}

    public function getUserBadgeFrom(#[\SensitiveParameter] string $accessToken): UserBadge
    {
        $token = $this->repository->findOneByValue($accessToken);

        if ($token === null || !$token->isValid()) {
            throw new BadCredentialsException('Invalid or expired token.');
        }

        return new UserBadge($token->getUser()->getUserIdentifier());
    }
}

AccessTokenHandlerInterface arayuzu tek bir metod gerektirir: getUserBadgeFrom. Bu metod, istekten cikarilan ham tokeni alir (varsayilan olarak Authorization: Bearer xxx basligi) ve iliskili kullanicinin tanimlayicisini iceren bir UserBadge nesnesi dondurmelidir. #[\SensitiveParameter] ozelligi, tokeni hassas veri olarak isaretleyerek stack trace'lerde ve loglarda gorunmesini engeller — PHP 8.2'de tanilan bir guvenlik en iyi uygulamasi.

Kalip kasitli olarak minimalisttir: token dogrulamasi (varlik, sure dolumu, iptal) repository veya ozel bir serviste kalir. Handler yalnizca bir tokeni kullanici kimligine donusturur. Bu sorumluluk ayrimi, birim testlerini kolaylastirir ve tek sorumluluk ilkesine uyar.

Voter'lar: ayrintili erisim kontrolu

Voter'lar, Symfony'de yetkilendirmenin merkezi mekanizmasini olusturur. access_control icerisinde tanimlanan statik rollerin aksine, voter'lar baglama dayali dinamik karar mantigi saglar: mevcut kullanici, hedef nesne ve istenen islem. Her voter, kesin bir soruyu yanitlar: "Bu kullanici, bu nesne uzerinde bu islemi gerceklestirebilir mi?"

namespace App\Security\Voter;

use App\Entity\Post;
use Symfony\Component\Security\Core\Authentication\Token\TokenInterface;
use Symfony\Component\Security\Core\Authorization\Voter\Vote;
use Symfony\Component\Security\Core\Authorization\Voter\Voter;
use Symfony\Component\Security\Core\User\UserInterface;

final class PostVoter extends Voter
{
    public const EDIT = 'POST_EDIT';
    public const DELETE = 'POST_DELETE';
    public const PUBLISH = 'POST_PUBLISH';

    protected function supports(string $attribute, mixed $subject): bool
    {
        return in_array($attribute, [self::EDIT, self::DELETE, self::PUBLISH])
            && $subject instanceof Post;
    }

    protected function voteOnAttribute(
        string $attribute,
        mixed $subject,
        TokenInterface $token,
        ?Vote $vote = null,
    ): bool {
        $user = $token->getUser();
        if (!$user instanceof UserInterface) {
            $vote?->addReason('User is not authenticated.');
            return false;
        }

        /** @var Post $post */
        $post = $subject;

        return match ($attribute) {
            self::EDIT => $this->canEdit($post, $user, $vote),
            self::DELETE => $this->canDelete($post, $user, $vote),
            self::PUBLISH => $this->canPublish($post, $user, $vote),
            default => false,
        };
    }

    private function canEdit(Post $post, UserInterface $user, ?Vote $vote): bool
    {
        if ($post->getAuthor() === $user) {
            $vote?->addReason('User is the author of the post.');
            return true;
        }

        $vote?->addReason('User is not the author.');
        return false;
    }

    private function canDelete(Post $post, UserInterface $user, ?Vote $vote): bool
    {
        if (in_array('ROLE_ADMIN', $user->getRoles())) {
            $vote?->addReason('User has ROLE_ADMIN.');
            return true;
        }

        if ($post->getAuthor() === $user && !$post->isPublished()) {
            $vote?->addReason('Author can delete unpublished posts.');
            return true;
        }

        $vote?->addReason('Only admins or authors of unpublished posts can delete.');
        return false;
    }

    private function canPublish(Post $post, UserInterface $user, ?Vote $vote): bool
    {
        if (in_array('ROLE_EDITOR', $user->getRoles())) {
            $vote?->addReason('User has ROLE_EDITOR.');
            return true;
        }

        $vote?->addReason('Only editors can publish posts.');
        return false;
    }
}

Bu voter'in birkac ogesinin ayrintili incelemesi gerekmektedir. Vote parametresi (Symfony 7.1'de tanitildi), her karara metinsel gerekce eklenmesini saglar ve gelistirme ortaminda hata ayiklamayi, uretimde denetlenebilirligi kolaylastirir. supports metodu cagrilari filtreler: voter yalnizca Post ornegi ile iliskili POST_EDIT, POST_DELETE ve POST_PUBLISH ozellikleri icin etkinlesir.

voteOnAttribute icindeki match ifadesi, mantigi her biri bir islemin is kurallarini kapsayan ozellestirilmis ozel metodlara devreder. Bu yapilandirma, voter'i okunabilir ve genisletilebilir kilar: yeni bir islem eklemek, bir sabit tanimlama, match icerisine bir durum ekleme ve bir ozel metod yazmakla sinirlidir.

canDelete mantigi sik rastlanan bir kalip sergilemektedir: rol dogrulamasi ile sahiplik dogrulamasinin birlestirilmesi. Bir yonetici herhangi bir makaleyi silebilir, ancak bir yazar yalnizca kendi yayinlanmamis makalelerini silebilir. Bu tur baglamsal kurallar, access_control icindeki basit rollerle ifade edilemez.

IsGranted ozelligi: bildirimsel erisim kontrolu

#[IsGranted] ozelligi, erisim kontrolunu dogrudan denetleyici veya metod duzeyinde uygular ve eski guvenlik anotasyonlariyla ayni islevi yerel PHP sozdizimi ile yerine getirir. Symfony, ifadeyi metod yurutulmeden once degerlendirir ve dogrulama basarisiz olursa 403 yaniti dondurur.

namespace App\Controller;

use App\Entity\Post;
use App\Security\Voter\PostVoter;
use Symfony\Bundle\FrameworkBundle\Controller\AbstractController;
use Symfony\Component\HttpFoundation\Response;
use Symfony\Component\Routing\Attribute\Route;
use Symfony\Component\Security\Http\Attribute\IsGranted;

#[Route('/post')]
final class PostController extends AbstractController
{
    #[Route('/{id}/edit', methods: ['GET', 'POST'])]
    #[IsGranted(PostVoter::EDIT, subject: 'post', message: 'You cannot edit this post.')]
    public function edit(Post $post): Response
    {
        // User is guaranteed to have edit permission at this point
        return $this->render('post/edit.html.twig', [
            'post' => $post,
        ]);
    }

    #[Route('/{id}/publish', methods: ['POST'])]
    #[IsGranted(PostVoter::PUBLISH, subject: 'post')]
    public function publish(Post $post): Response
    {
        // Only editors reach this code
        $post->setPublished(true);
        // ...
        return $this->redirectToRoute('post_show', ['id' => $post->getId()]);
    }
}

subject: 'post' parametresi, ozelligi ayni isimdeki metod parametresine baglar. Symfony, varlik cozumlemesini ParamConverter araciligiyla otomatik olarak yapar ve dogrulama konusu olarak voter'a iletir. message parametresi 403 hata mesajini ozellestirerek hem hata ayiklama hem de denetim loglari icin faydalidir.

Bu bildirimsel yaklasiMin okunabilirlik acisindan onemli bir avantaji vardir: erisim kurallari, islevin govdesinin incelenmesine gerek kalmadan metod imzasiyla ayni yerde gorulur. Teknik mulakatlarda, ozellikten voter'a ve AccessDecisionManager'a uzanan tam yolu aciklayabilmek, Security bilesenine iliskin derin bir anlayis sergilemektedir.

Karar stratejileri: unanimous, affirmative, consensus

Birden fazla voter ayni erisim dogrulamasi hakkinda gorusunu bildirdiginde, AccessDecisionManager oylari toplamak icin bir karar stratejisi uygular. Symfony, security.yaml icerisinde yapilandirilabilir uc strateji sunar.

# config/packages/security.yaml
security:
    access_decision_manager:
        strategy: unanimous
        allow_if_all_abstain: false

affirmative stratejisi (varsayilan), tek bir voter olumlu oy verdiginde erisim izni verir. unanimous stratejisi, cekinser olmayan tum voter'larin olumlu oy vermesini gerektirir. consensus stratejisi, voter'larin cogunlugu olumlu oy verdiginde erisim izni verir. allow_if_all_abstain parametresi, tum voter'lar cekinser kaldiginda (hicbiri istenen ozelligi desteklemediklerinde) davranisi belirler.

Pratikte, varsayilan affirmative stratejisi cogu uygulama icin yeterlidir. unanimous stratejisi, guvenligin oncelikli oldugu baglamlarda dayatilir: finansal uygulamalar, tibbi veriler, kritik sistemler. Hicbir voter'in erisime itiraz etmedigini garanti ederek derinlemesine savunma katmani ekler. IP dogrulama voter'i, rol voter'i ve sahiplik voter'inin tumunun erisimi onaylamasi gerekir.

Twig'de erisim karari hata ayiklama (Symfony 7.4)

Symfony 7.4, erisim kararlarina iliskin gerekceri dogrudan Twig sablonlarinda sunarak guvenlik sistemi hata ayiklamasini zenginlestirmektedir. Voter'lara eklenen Vote parametresi burada tam anlamini bulmaktadir: $vote->addReason() ile bildirilen gerekceleri Profiler'da goruntulenir ve sablonlarda kosullu olarak gosterilebilir.

{# templates/post/show.html.twig #}
{% if is_granted('POST_EDIT', post) %}
    <a href="{{ path('post_edit', {id: post.id}) }}">Edit</a>
{% endif %}

{% if is_granted('POST_DELETE', post) %}
    <form method="post" action="{{ path('post_delete', {id: post.id}) }}">
        <button type="submit">Delete</button>
    </form>
{% endif %}

{% if app.debug %}
    {# Symfony 7.4: access decision debugging in Twig #}
    {% set decision = is_granted_debug('POST_EDIT', post) %}
    <details>
        <summary>Access Decision Debug</summary>
        <ul>
            {% for voter_detail in decision.voterDetails %}
                <li>
                    {{ voter_detail.class }}:
                    {{ voter_detail.result > 0 ? 'GRANTED' : (voter_detail.result < 0 ? 'DENIED' : 'ABSTAIN') }}
                    {% for reason in voter_detail.reasons %}
                        <br>&rarr; {{ reason }}
                    {% endfor %}
                </li>
            {% endfor %}
        </ul>
    </details>
{% endif %}

is_granted() fonksiyonu, Twig'de erisim dogrulamalari icin standart giris noktasi olmaya devam etmektedir. Goruntuleme kosullarindaki kullanimi, arayuz ogelerinin (butonlar, baglantilar) yalnizca yetkili kullanicilar icin gorulur olmasini garanti eder. app.debug ile kosullandirilan hata ayiklama bloku, bu bilgileri uretimde aciga cikarmadan gelistirme ortaminda oylama detaylarinin incelenmesini saglar.

Bu hata ayiklama mekanizmasi, Symfony projelerinde yinelenen bir soruna cevap vermektedir: bir kullanicinin erisiminin neden reddedildiginin belirlenmesi. Symfony 7.4'ten once bu arastirma, Profiler'in manuel incelemesini veya voter'lara gecici log eklenmesini gerektiriyordu.

Voter'larin birim testleri

Voter'lar kritik is kurallarini kapsuller ve kapsamli test kapsamasi gerektirir. Yetkilendirme sisteminin tutarliligini garanti etmek icin her kullanici/islem/nesne kombinasyonu dogrulanmalidir.

namespace App\Tests\Security\Voter;

use App\Entity\Post;
use App\Entity\User;
use App\Security\Voter\PostVoter;
use PHPUnit\Framework\TestCase;
use Symfony\Component\Security\Core\Authentication\Token\UsernamePasswordToken;
use Symfony\Component\Security\Core\Authorization\Voter\VoterInterface;

final class PostVoterTest extends TestCase
{
    private PostVoter $voter;

    protected function setUp(): void
    {
        $this->voter = new PostVoter();
    }

    public function testAuthorCanEditOwnPost(): void
    {
        $user = new User();
        $post = (new Post())->setAuthor($user);
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_GRANTED,
            $this->voter->vote($token, $post, [PostVoter::EDIT]),
        );
    }

    public function testNonAuthorCannotEditPost(): void
    {
        $author = new User();
        $otherUser = new User();
        $post = (new Post())->setAuthor($author);
        $token = new UsernamePasswordToken($otherUser, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_DENIED,
            $this->voter->vote($token, $post, [PostVoter::EDIT]),
        );
    }

    public function testAdminCanDeleteAnyPost(): void
    {
        $admin = new User();
        $post = (new Post())->setAuthor(new User());
        $token = new UsernamePasswordToken($admin, 'main', ['ROLE_ADMIN']);

        $this->assertSame(
            VoterInterface::ACCESS_GRANTED,
            $this->voter->vote($token, $post, [PostVoter::DELETE]),
        );
    }

    public function testAuthorCanDeleteUnpublishedPost(): void
    {
        $user = new User();
        $post = (new Post())->setAuthor($user)->setPublished(false);
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_GRANTED,
            $this->voter->vote($token, $post, [PostVoter::DELETE]),
        );
    }

    public function testAuthorCannotDeletePublishedPost(): void
    {
        $user = new User();
        $post = (new Post())->setAuthor($user)->setPublished(true);
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_DENIED,
            $this->voter->vote($token, $post, [PostVoter::DELETE]),
        );
    }

    public function testOnlyEditorCanPublish(): void
    {
        $user = new User();
        $post = (new Post())->setAuthor($user);
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_EDITOR']);

        $this->assertSame(
            VoterInterface::ACCESS_GRANTED,
            $this->voter->vote($token, $post, [PostVoter::PUBLISH]),
        );
    }

    public function testVoterAbstainsOnUnsupportedAttribute(): void
    {
        $user = new User();
        $post = new Post();
        $token = new UsernamePasswordToken($user, 'main', ['ROLE_USER']);

        $this->assertSame(
            VoterInterface::ACCESS_ABSTAIN,
            $this->voter->vote($token, $post, ['UNSUPPORTED']),
        );
    }
}

Her test, belirli bir is kuralini izole eder. testAuthorCannotDeletePublishedPost testi, yazarin yayinlamadan sonra silme hakkini kaybettigine dair kisitlamayi dogrular — testlerin yoklugunda kolayca gozden kacabilecek bir kural. Desteklenmeyen bir ozellik uzerindeki cekinserlik testi, voter'in diger voter'larin kararlarina mudahale etmedigini dogrular.

Voter'lar, framework bagimliligina sahip olmayan saf PHP siniflaridir (bu ornekte enjekte edilen servis bulunmamaktadir), bu da PHPUnit ile basit birim testlerini mumkun kilar. Servislere ihtiyac duyan daha karmasik voter'lar icin (abonelik dogrulamasi, kota sinirlari), createMock() ile bagimliliklarin mock'lanmasi standart yaklasim olmaya devam etmektedir.

Guvenlik guclendirme: UserChecker ve en iyi uygulamalar

Voter'lar ve firewall'larin otesinde, Symfony guvenlik guclendirmesi birkac tamamlayici mekanizma araciligiyla gerceklestirilir. UserCheckerInterface, kimlik dogrulama sirasinda kimlik bilgilerinin dogrulanmasindan once ve sonra ek kontroller eklenmesini saglar.

namespace App\Security;

use App\Entity\User;
use Symfony\Component\Security\Core\Exception\CustomUserMessageAccountStatusException;
use Symfony\Component\Security\Core\User\UserCheckerInterface;
use Symfony\Component\Security\Core\User\UserInterface;

final class UserEnabledChecker implements UserCheckerInterface
{
    public function checkPreAuth(UserInterface $user): void
    {
        if (!$user instanceof User) {
            return;
        }

        if ($user->isBanned()) {
            throw new CustomUserMessageAccountStatusException(
                'Your account has been banned. Contact support.'
            );
        }
    }

    public function checkPostAuth(UserInterface $user): void
    {
        if (!$user instanceof User) {
            return;
        }

        if (!$user->isVerified()) {
            throw new CustomUserMessageAccountStatusException(
                'Please verify your email address before logging in.'
            );
        }
    }
}

UserChecker, dogrulamalari iki asamaya ayirir: checkPreAuth parola dogrulamadan once yurutulur (yasaklanmis bir kullanici durumu — kimlik bilgilerini kontrol etmenin anlami yoktur), checkPostAuth sonra yurutulur (dogrulanmamis e-posta durumu — parola dogru ancak hesap henuz aktif degil). Bu ayrim, kimlik dogrulama akisini optimize eder ve her durum icin ozel hata mesajlari saglar.

Tamamlayici guvenlik guclendirme en iyi uygulamalari sunlari icerir:

• Hiz sinirlandirma: Symfony ile entegre RateLimiter bileseni, IP veya kullanici tanimlayicisina gore giris denemelerini sinirlandirarak kaba kuvvet saldirilarini onler
• CSRF korumasi: Giris formu dahil tum formlarda CSRF korumasinin firewall'un enable_csrf parametresi araciligiyla etkinlestirilmesi
• Parola hashleme: Kullanilabilir en guvenli algoritmani otomatik olarak secen auto hasher'in kullanilmasi (PHP kurulumuna gore bcrypt veya Argon2id)
• Gizli bilgi rotasyonu: Hassas kimlik bilgileri icin Symfony Vault'unun kullanilmasi, otomatik sifreleme anahtari rotasyonu ile
• Guvenlik basiklari: Content-Security-Policy, X-Frame-Options, Strict-Transport-Security HTTP basliklarinin kernel.response uzerindeki bir event listener araciligiyla yapilandirilmasi

Teknik mulakat sorulari

Symfony guvenligi, PHP backend teknik mulakatlarinda vazgecilmez bir konuyu olusturmaktadir. Asagidaki sorular, ise alim uzmanlari tarafindan degerlendirilen konulari, orta seviyeden senior seviyeye kadar kapsamaktadir.

Symfony'de kimlik dogrulama ile yetkilendirme arasindaki fark nedir? Kimlik dogrulama, "Kimsiniz?" sorusunu yanitlar — kullaniciyi kimlik bilgileri (kullanici adi/parola, API tokeni, sertifika) araciligiyla tanir. Yetkilendirme, "Hakkiniz var mi?" sorusunu yanitlar — kimlik dogrulamas yapilmis kullanicinin izinlerini roller, voter'lar ve guvenlik ifadeleri araciligiyla dogrular. Symfony'de firewall kimlik dogrulamayi yonetirken, AccessDecisionManager ve voter'lar yetkilendirmeyi yonetir.

Voter nasil calisir ve ne zaman access_control yerine tercih edilmelidir? Bir voter, VoterInterface'i uygular ve uc degere yanitlar: ACCESS_GRANTED, ACCESS_DENIED veya ACCESS_ABSTAIN. Voter'lar, erisim karari baglama baglidiginde tercih edilir: hedef nesne (Post, Siparis), bu nesnenin durumu (yayinlanmis, arsivlenmis) veya kullanici ile nesne arasindaki iliski (yazar, yonetici). security.yaml icindeki access_control kurallari, statik rol ve URL kalip dogrulalariyla sinirlidir.

Symfony 7.1'de tainitlan Vote parametresinin rolu nedir? Vote parametresi, voter'larin kararlarina metinsel gerekce eklemesini saglar. Bu gerekceleri Symfony Profiler'da goruntulenir ve hata ayiklama icin Twig sablonlarinda kullanilabilir. Uretimde denetim loglarini besler. Parametre istege baglidir ve nullable'dir (?Vote $vote = null), mevcut voter'larla geriye donuk uyumlulugu korumak icin.

Symfony'de stateless bir API nasil guvence altina alinir? Firewall, oturum yonetimini devre disi birakmak icin stateless: true ile yapilandirilmalidir. Kimlik dogrulama, her istekten tokeni cikarip dogrulayan bir AccessTokenHandler'a dayanir. Tokenler sinirli bir yasam suresine sahip olmali, istemci tarafinda guvenli bir sekilde saklanmali ve sunucu tarafinda iptal edilebilir olmalidir. Token parametresindeki #[\SensitiveParameter] bayraqi, loglara ve stack trace'lere sizmayi onler.

Voter'lar kapsamli olarak nasil test edilir? Voter'lar, PHPUnit ile standart PHP siniflari olarak test edilir. Her test voter'i ornekler, belirli roller ile bir kullaniciyi simule eden bir UsernamePasswordToken olusturur, istenen durumda hedef nesneyi yaratir ve vote() metodunun beklenen degeri (ACCESS_GRANTED, ACCESS_DENIED veya ACCESS_ABSTAIN) dondurdugunu dogrular. Kapsam, desteklenen tum ozellikleri, sinir durumlarini (kimlik dogrulamasi yapilmamis kullanici, desteklenmeyen ozellik) ve rol kombinasyonlarini icermelidir.

Sonuc

Symfony'nin Security bileseni, klasik form kimlik dogrulamasindan dagitik ortamlardaki cok kriterli yetkilendirme sistemlerine kadar uzanan senaryolari kapsayabilen, hem titiz hem de genisletilebilir bir mimari sunmaktadir. Hakimiyeti, teknik mulakatlarda tartismasiz bir senior seviye gostergesi olusturmaktadir.

Hatirlanmasi gereken temel noktalar:

• Firewall'lar: tanim sirasi eslesmeyi belirler; security: false yalnizca gelistirme rotalari icin kullanilmali, uretimde asla
• Stateless ve stateful: tercih mimariye baglidir (monolit vs mikroservisler), teknik tercihe degil
• Access Token Handler: AccessTokenHandlerInterface arayuzu, tek bir metodla token yonetimini birlestirerek testleri ve bakimi kolaylastirir
• Voter'lar: baglamsal yetkilendirme mantigi icin voter'lari tercih etmek; her voter'i islem basina ozel metodlarla yapilandirmak
• Vote parametresi: erisim karari hata ayiklama ve denetlenebilirligi icin addReason() kullanmak
• IsGranted: maksimum okunabilirlik icin erisim kontrolunu denetleyici duzeyinde bildirimsel olarak uygulamak
• Karar stratejileri: derinlemesine savunma gerektiren hassas baglamlarda unanimous secmek
• Testler: voter birim testlerinde her kullanici/islem/nesne kombinasyonunu kapsamak
• Guclendirme: cok katmanli savunma icin UserChecker, hiz sinirlandirma, CSRF, guvenlik basiklari ve gizli bilgi rotasyonunu birlestirmek