Symfony2 \ SecurityBundle

लेखक सुरक्षा बंडल के डिवाइस के बारे में बात करता है (मेरी राय में, सिम्फनी शुरुआती के लिए समझना सबसे मुश्किल है) और इसके आवेदन का एक उदाहरण का विश्लेषण करता है। यह लेख उन लोगों के लिए विशेष रूप से उपयोगी होगा जो यह जानना चाहते हैं कि उनका उपकरण कैसे काम करता है: Symfony2 Security in General और FOSUserBundle विशेष रूप से - हालांकि, यह फ्रेमवर्क के साथ पहले परिचित के लिए उपयुक्त नहीं है, क्योंकि इसके कुछ घटकों के ज्ञान की आवश्यकता होती है।
यह लेख 21 मार्च, 2011 को प्रकाशित हुआ था, जब सिम्फनी 2.0 का अंतिम संस्करण अभी तक जारी नहीं किया गया था, लेकिन बंडल के सिद्धांत नहीं बदले।

मूल लेख, "Symfony2 ब्लॉग अनुप्रयोग ट्यूटोरियल भाग V: पहचान में सुरक्षा," एक ब्लॉग बनाने पर ट्यूटोरियल लेख की एक श्रृंखला का हिस्सा है।
लेख का एक सीधा निरंतरता / परिवर्धन है - "सिम्फनी 2 ब्लॉग एप्लीकेशन ट्यूटोरियल पार्ट वी -2: टेस्टिंग सिक्योर पेज" , जो एप्लिकेशन के "बंद" भागों के परीक्षण का एक उदाहरण देता है।

लेख पाठ

Symfony2 में सुरक्षा घटक बहुत शक्तिशाली और जटिल है। नीचे दिए गए उदाहरण सरल होंगे, लेकिन आपके लिए इसे अपनी आवश्यकताओं को पूरा करना मुश्किल नहीं होना चाहिए। अनुप्रयोगों के उत्पादन संस्करणों में, FOSUserBundle बंडल का उपयोग करने की अत्यधिक अनुशंसा की जाती है, जो यहां पाया जा सकता है । इसके लेखक Symfony2 के मूल के डेवलपर्स में से हैं, और सबसे अधिक संभावना है कि बंडल "sfGuardPlugin" जैसा कुछ हो जाएगा, केवल फ्रेमवर्क के दूसरे संस्करण के लिए। सिम्फनी 1 से परिचित लोग मुझे समझेंगे। चूंकि लोगों को बंडल के साथ समस्या है, इसलिए मैं इस प्रक्रिया को तेज करने के लिए लेखन परीक्षण को छोड़ दूंगा। शायद मैं उन्हें बाद में लिखूंगा और पोस्ट को अपडेट करूंगा। [ अद्यतन: मैंने ऐसा किया, यहां देखें।]

तो, हमारा लक्ष्य किसी ऐसे व्यक्ति की आवश्यकता है, जो फॉर्म के माध्यम से लॉग इन करने के लिए "/ व्यवस्थापक /" के साथ शुरुआत में प्रवेश करने की कोशिश करता है। ऐसा करने के लिए, हमें कुछ चीजें करने की जरूरत है। सबसे पहले आपको SecurityBundle को पंजीकृत करना होगा जो Symfony2 के साथ आता है। ऐसा करने के लिए, ऐप डायरेक्टरी में स्थित AppKernel.php को खोलें, रजिस्टरबंडल्स विधि ढूंढें और निम्नलिखित को बंडल सरणी में जोड़ें:

new Symfony\Bundle\SecurityBundle\SecurityBundle() 

अब जब बंडल पंजीकृत हो गया है, तो आप व्यापार में उतर सकते हैं, लेकिन इससे पहले कि आप कोड लिखना शुरू करें, आपको सिम्फनी 2 में सुरक्षा घटक के सिद्धांतों को समझने की आवश्यकता है। परंपरागत रूप से, इसे तीन उप-विभाजकों में विभाजित किया जा सकता है: उपयोगकर्ता, प्रमाणीकरण और प्राधिकरण। उपयोगकर्ता एप्लिकेशन के साथ काम करने वाले उपयोगकर्ता के बारे में जानकारी संग्रहीत करता है। प्रमाणीकरण जाँचता है कि उपयोगकर्ता कौन है। प्राधिकरण एक प्रमाणित उपयोगकर्ता को कुछ कार्यों को करने की अनुमति देता है और प्रतिबंधित करता है, उदाहरण के लिए, किसी भी जानकारी को देखना, उसका संपादन करना आदि।

अब हम अपने आवेदन में सुरक्षा प्रणाली को कॉन्फ़िगर करने के लिए तैयार हैं। ऐसा करने के लिए, हम Symfony2 कॉन्फ़िगरेशन में इंगित करते हैं कि उपयोगकर्ता प्रदाता के रूप में हमें पहले बनाए गए Company \ BlogBundle \ Entity \ User इकाई का उपयोग करना चाहिए, और यह भी परिभाषित करना चाहिए कि पासवर्ड कैसे एन्क्रिप्ट करें, एप्लिकेशन के किन हिस्सों को संरक्षित किया जाना चाहिए और उपयोगकर्ता को कौन सी भूमिकाएं होनी चाहिए। उन तक पहुँचने के लिए। एप्लिकेशन / कॉन्फ़िगरेशन निर्देशिका से config.yml फ़ाइल खोलें और निम्नलिखित जोड़ें:

 ## Security Configuration security: encoders: Company\BlogBundle\Entity\User: algorithm: sha512 encode-as-base64: true iterations: 10 providers: main: entity: { class: BlogBundle:User, property: username } firewalls: main: pattern: /.* form_login: check_path: /login_check login_path: /login logout: true security: true anonymous: true access_control: - { path: /admin/.*, role: ROLE_ADMIN } - { path: /.*, role: IS_AUTHENTICATED_ANONYMOUSLY } 

आइए इस फ़ाइल के प्रत्येक अनुभाग का विश्लेषण करें। एन्कोडर यह निर्धारित करते हैं कि कंपनी \ BlogBundle \ Entity \ उपयोगकर्ता इकाई के लिए उपयोगकर्ता पासवर्ड कैसे एन्क्रिप्ट किए जाएंगे। हम SymDony2 के साथ आने वाले MessageDigestPasswordEncoder का उपयोग करेंगे, लेकिन निश्चित रूप से, आप अपना खुद का एनकोडर लिख सकते हैं। (नोट: MessageDigestPasswordEncoder वर्ग विक्रेता / सिम्फनी / src / Symfony / Component / Security / Core / Encoder पर स्थित है।) निम्नलिखित संकेत देता है कि sha512 के माध्यम से 10 रन एन्क्रिप्शन के साथ उपयोग किए जाने चाहिए, और परिणाम को base64 स्ट्रिंग के रूप में प्रस्तुत किया जाना चाहिए। एनकोडर के बारे में अधिक जानकारी के लिए, यहां देखें।

प्रदाता अनुभाग यह निर्धारित करता है कि उपयोगकर्ता डेटा को कहां पुनर्प्राप्त करना है। हमने डॉक्ट्रिन एंटिटी प्रोवाइडर को चुना और इसके लिए हमने यूनिट पैरामीटर निर्दिष्ट किया। अन्य अनुमत प्रदाता इन-मेमोरी प्रदाता और चेन प्रदाता हैं , जिनके बारे में आप यहां पढ़ सकते हैं। इकाई लाइन को वर्ग और संपत्ति गुणों को निर्दिष्ट करना होगा। उपयोगकर्ता को दर्शाने वाली इकाई के साथ कक्षा का वर्ग। उदाहरण में, यह BlogBundle बंडल से उपयोगकर्ता वर्ग है। संपत्ति उपयोगकर्ता नाम वाली तालिका के कॉलम का नाम है, और हमारे मामले में यह उपयोगकर्ता नाम है।

सिम्फनी 2 में प्राधिकरण फ़ायरवॉल सिस्टम के माध्यम से कार्यान्वित किया जाता है। इसमें "श्रोता" (अंग्रेजी सुनने वाले) शामिल होते हैं, जो एक core.security घटना की अपेक्षा करते हैं और अनुरोध को पुनर्निर्देशित करते हैं, जो उपयोगकर्ता के अधिकार को ध्यान में रखते हैं। फायरवॉल अनुभाग मार्ग के पैटर्न (अंग्रेजी मार्गों) को परिभाषित करता है, जिस पर आपको "श्रोताओं" (अंग्रेजी सुनने वाले) को लटकाए जाने की आवश्यकता होती है। आज, एप्लिकेशन की सुरक्षा के लिए, यह एक फ़ायरवॉल निर्दिष्ट करने की अनुशंसा की जाती है जो सभी मार्गों पर कार्य करती है, और फिर उपयोगकर्ता की भूमिकाओं के आधार पर, एक्सेस या अस्वीकार करने के लिए access_control अनुभाग का उपयोग करें। हमारे उदाहरण में, फायरवॉल अनुभाग के पैटर्न क्षेत्र में, यह निर्धारित किया जाता है कि सभी मार्गों को "सुनी" जाना चाहिए। Form_login फ़ील्ड इंगित करता है कि प्रमाणीकरण फ़ॉर्म से होकर गुजरेगा। अन्य प्रमाणीकरण विधियों के लिए, यहां देखें। Form_login के अंदर , हमने login_path (लॉगिन फ़ॉर्म का स्थान) और check_path (फ़ॉर्म हैंडलर का स्थान) के लिए मार्ग निर्दिष्ट किए हैं। इसके अलावा, form_login में कई अन्य सेटिंग्स हैं जिनके बारे में यहां पढ़ा जा सकता है ।

अंत में, अंतिम अनुभाग access_control है । इसमें प्रविष्टियां मार्ग के पैटर्न और भूमिकाओं को परिभाषित करती हैं, जिससे उन्हें एक्सेस करने की आवश्यकता होती है। हमारे उदाहरण में, "/ व्यवस्थापक /" के साथ शुरू होने वाले मार्गों के लिए ROLE_ADMIN भूमिका आवश्यक है, सभी के लिए IS_AUTHENTICATED_ANONYMOUSLY पर्याप्त है (Symfony2 में, सभी उपयोगकर्ताओं को डिफ़ॉल्ट रूप से यह भूमिका सौंपी गई है)।

इसलिए, अब जब सुरक्षा कॉन्फ़िगरेशन फ़ाइल को अपडेट किया गया है, तो हमें अपनी इकाई कक्षाओं को बदलने की आवश्यकता है ताकि वे उन इंटरफेसों को कार्यान्वित करें जिन्हें SecurityBundal की आवश्यकता है। हमारे उदाहरण में, हमें उपयोगकर्ता इकाई में UserInterface इंटरफ़ेस कार्यान्वयन को जोड़ना होगा। आपको रोल क्लास बनाने की भी आवश्यकता है जो रोल इन्टरफेस इंटरफ़ेस को लागू करता है। उसके बाद, डेटाबेस में नई जानकारी अपलोड करने के लिए, हमें अपने जुड़नार को बदलने की आवश्यकता है।

निम्नलिखित सामग्री के साथ src / Company / BlogBundle / Entity निर्देशिका में एक रोल.फैप फ़ाइल बनाएँ:

 namespace Company\BlogBundle\Entity; use Symfony\Component\Security\Core\Role\RoleInterface; use Doctrine\ORM\Mapping as ORM; /** * @ORM\Entity * @ORM\Table(name="role") */ class Role implements RoleInterface { /** * @ORM\Id * @ORM\Column(type="integer") * @ORM\GeneratedValue(strategy="AUTO") * * @var integer $id */ protected $id; /** * @ORM\Column(type="string", length="255") * * @var string $name */ protected $name; /** * @ORM\Column(type="datetime", name="created_at") * * @var DateTime $createdAt */ protected $createdAt; /** *   id. * * @return integer The id. */ public function getId() { return $this->id; } /** *    . * * @return string The name. */ public function getName() { return $this->name; } /** *    . * * @param string $value The name. */ public function setName($value) { $this->name = $value; } /** *     . * * @return DateTime A DateTime object. */ public function getCreatedAt() { return $this->createdAt; } /** *   */ public function __construct() { $this->createdAt = new \DateTime(); } /** *  ,   RoleInterface. * * @return string The role. */ public function getRole() { return $this->getName(); } } 

भूमिका का सार काफी सरल है। इसकी केवल एक संपत्ति है - नाम , जिसमें भूमिका का नाम शामिल है। क्लास गेट रोल विधि के लिए समर्थन के माध्यम से रोल इन्टरफेस इंटरफेस को भी लागू करता है, जो भूमिका का नाम देता है। अब, रोल क्लास बनाने के बाद, आपको उपयोगकर्ता इकाई को ट्विक करने की आवश्यकता है। से User.php फ़ाइल खोलें
src / Company / BlogBundle / Entity और कोड को निम्नानुसार बदलें:

 namespace Company\BlogBundle\Entity; use Doctrine\Common\Collections\ArrayCollection; use Doctrine\ORM\Mapping as ORM; use Symfony\Component\Security\Core\User\UserInterface; /** * @ORM\Entity * @ORM\Table(name="user") */ class User implements UserInterface { // ... /** * @ORM\Column(type="string", length="255") * * @var string username */ protected $username; /** * @ORM\Column(type="string", length="255") * * @var string password */ protected $password; /** * @ORM\Column(type="string", length="255") * * @var string salt */ protected $salt; /** * @ORM\ManyToMany(targetEntity="Role") * @ORM\JoinTable(name="user_role", * joinColumns={@ORM\JoinColumn(name="user_id", referencedColumnName="id")}, * inverseJoinColumns={@ORM\JoinColumn(name="role_id", referencedColumnName="id")} * ) * * @var ArrayCollection $userRoles */ protected $userRoles; // ... /** *    . * * @return string The username. */ public function getUsername() { return $this->username; } /** *    . * * @param string $value The username. */ public function setUsername($value) { $this->username = $value; } /** *   . * * @return string The password. */ public function getPassword() { return $this->password; } /** *   . * * @param string $value The password. */ public function setPassword($value) { $this->password = $value; } /** *     . * * @return string The salt. */ public function getSalt() { return $this->salt; } /** *     . * * @param string $value The salt. */ public function setSalt($value) { $this->salt = $value; } /** *    . * * @return ArrayCollection A Doctrine ArrayCollection */ public function getUserRoles() { return $this->userRoles; } /** *   User */ public function __construct() { $this->posts = new ArrayCollection(); $this->userRoles = new ArrayCollection(); $this->createdAt = new \DateTime(); } /** *   . */ public function eraseCredentials() { } /** *    . * * @return array An array of Role objects */ public function getRoles() { return $this->getUserRoles()->toArray(); } /** *        *       . * * @param UserInterface $user The user * @return boolean True if equal, false othwerwise. */ public function equals(UserInterface $user) { return md5($this->getUsername()) == md5($user->getUsername()); } // ... } 

जो लोग इस वर्ग को यहां डाउनलोड कर सकते हैं । जैसा कि आप देख सकते हैं, उपयोगकर्ता इकाई में विशेष रूप से कुछ भी जटिल नहीं है, बस UserInterface इंटरफ़ेस का कार्यान्वयन और भूमिका इकाई के साथ कई-से-कई संबंधों का निर्माण। एक AdvancedUserInterface इंटरफ़ेस भी है जो अधिक कार्यक्षमता प्रदान करता है, लेकिन इसका विचार इस लेख के दायरे से परे है। आप इसके बारे में और अधिक यहाँ पढ़ सकते हैं।

अब आपको जुड़नार बदलने की आवश्यकता है, जिसके साथ हम डेटाबेस में जानकारी अपडेट कर सकते हैं। FixtureLoader.php फ़ाइल को src / Company / BlogBundle / DataFixtures / ORM निर्देशिका से खोलें और निम्नलिखित परिवर्तन करें:

 namespace Company\BlogBundle\DataFixtures\ORM; use Doctrine\Common\DataFixtures\FixtureInterface; use Company\BlogBundle\Entity\Category; use Company\BlogBundle\Entity\Post; use Company\BlogBundle\Entity\Tag; use Company\BlogBundle\Entity\User; use Company\BlogBundle\Entity\Role; use Symfony\Component\Security\Core\Encoder\MessageDigestPasswordEncoder; class FixtureLoader implements FixtureInterface { public function load($manager) { //   ROLE_ADMIN $role = new Role(); $role->setName('ROLE_ADMIN'); $manager->persist($role); //   $user = new User(); $user->setFirstName('John'); $user->setLastName('Doe'); $user->setEmail('john@example.com'); $user->setUsername('john.doe'); $user->setSalt(md5(time())); //      , //       $encoder = new MessageDigestPasswordEncoder('sha512', true, 10); $password = $encoder->encodePassword('admin', $user->getSalt()); $user->setPassword($password); $user->getUserRoles()->add($role); $manager->persist($user); // ... } 

इस प्रकार, एक नई भूमिका ROLE_ADMIN नाम से बनाई गई थी। John.doe उपयोगकर्ता नाम और मनमाना पासवर्ड नमक वाला उपयोगकर्ता भी जोड़ा गया था। यहां केवल नई कार्यक्षमता पासवर्ड एन्क्रिप्शन है। यदि आपको याद है, तो कॉन्फ़िगरेशन फ़ाइल के सुरक्षा.चेंजर्स अनुभाग में हमने MessageDigestPasswordEnccoder का उपयोग निर्धारित किया है। यहां हम इस वर्ग का एक उदाहरण बनाते हैं और इसमें वही पैरामीटर पास करते हैं जो सुरक्षा में निर्दिष्ट होते हैं। पेनोडर्स , फिर पासवर्ड "व्यवस्थापक" को एन्क्रिप्ट करें और परिणाम को उपयोगकर्ता के लिए नए पासवर्ड के रूप में सेट करें। पासवर्ड एन्क्रिप्ट करते समय, आपको सुरक्षा पैरामीटर के कॉन्फ़िगरेशन में समान पैरामीटर निर्दिष्ट करना होगा, क्योंकि अन्यथा हम सही तरीके से प्रमाणित नहीं कर पाएंगे।

रूटिंग को अपडेट करने और नए नियंत्रक और विचार बनाने से पहले, आपको कंसोल में कई कमांड चलाने की आवश्यकता है। टर्मिनल खोलें और हमारी परियोजना की मूल निर्देशिका पर जाएं। सबसे पहले, संस्थाओं से मिलान करने के लिए डेटाबेस संरचना को अपडेट करें।

 php app/console doctrine:schema:update --force 

अगला, हम डेटाबेस को साफ़ करते हैं और अद्यतन जुड़नार का उपयोग करके जानकारी को फिर से लोड करते हैं।

 php app/console doctrine:data:load 

इस स्तर पर, हमने इकाइयां, डेटा और एक सुरक्षा कॉन्फ़िगरेशन स्थापित और अद्यतन किया है। अब आइए लॉगिन फॉर्म को लागू करने के लिए रूटिंग को बदलना शुरू करें और कई नियंत्रक और विचार बनाएं। Src / Company / BlogBundle / Resources / config directory से routing.yml फ़ाइल खोलें और इसके लिए निम्नलिखित मार्ग जोड़ें:

 _security_login: pattern: /login defaults: { _controller: BlogBundle:Security:login } _security_check: pattern: /login_check _security_logout: pattern: /logout admin_home: pattern: /admin/ defaults: { _controller: BlogBundle:Admin:index } 

इस तरह, हमने कई विशेष मार्गों को जोड़ा जो कि हमारे द्वारा और सुरक्षा घटक द्वारा उपयोग किए जाएंगे। आप सोच रहे होंगे कि हमने दो मार्गों के लिए नियंत्रकों को परिभाषित क्यों नहीं किया। याद रखें कि मैंने सुरक्षा घटक के संचालन के बारे में क्या लिखा था, जो एक core.security घटना की अपेक्षा करता है? यह इस प्रकार है कि इन मार्गों के लिए नियंत्रकों को कभी भी निष्पादित नहीं किया जाएगा, क्योंकि सुरक्षा घटक अनुरोधों को स्वीकार करता है और उन्हें स्वयं संसाधित करता है। इसलिए, हम अपने टेम्प्लेट्स में आसानी से _security_check और _security_logout मार्गों का उपयोग कर सकते हैं। एक admin_home रूट भी जोड़ा गया है, जो हमारे एप्लिकेशन के एडमिन सेक्शन का मुख्य पेज है। चूंकि हमने Security.access_control कॉन्फ़िगरेशन सेक्शन में संकेत दिया था कि केवल ROLE_ADMIN भूमिका वाले उपयोगकर्ता "/ व्यवस्थापक /" से शुरू होने वाले मार्गों तक पहुँच सकते हैं, इसलिए admin_home मार्ग सुरक्षित है। जल्द ही हम इसे दर्ज करने की कोशिश करेंगे।

आपने शायद ध्यान दिया कि हमें दो नए नियंत्रक बनाने की आवश्यकता है - SecurityController और AdminController , तो चलो शुरू करें। Src / Company / BlogBundle / नियंत्रक निर्देशिका में एक फ़ाइल बनाएँ, जिसका नाम AdminController.php और निम्नलिखित जानकारी है:

 namespace Company\BlogBundle\Controller; use Symfony\Bundle\FrameworkBundle\Controller\Controller; class AdminController extends Controller { public function indexAction() { return $this->render('BlogBundle:Admin:index.html.twig'); } } 

साधारण से बाहर कुछ भी नहीं। बस index.html.twig टेम्प्लेट को प्रोसेस करना, जिसे हम अब वर्णन करेंगे। ऐसा करने के लिए, src / Company / BlogBunde / Resources / views निर्देशिका में एक नया व्यवस्थापक फ़ोल्डर बनाएं, जिसके अंदर index.html.twig फ़ाइल - व्यवस्थापक अनुभाग के मुख्य पृष्ठ के लिए टेम्पलेट बनाएं।

 {% extends "BlogBundle::layout.html.twig" %} {% block title %} symfony2  |  |  {% endblock %} {% block content %} <h2>     , {{ app.user.username }}! </h2> {% endblock %} 

केवल एक चीज जिस पर आपको ध्यान देना चाहिए, वह app.user टेम्पलेट वैरिएबल है , जो आपको एप्लिकेशन में लॉग किए गए वर्तमान उपयोगकर्ता तक पहुंचने की अनुमति देता है। इसलिए, हमारे उदाहरण में, वैरिएबल app.user क्लास कंपनी \ BlogBundle \ Entity \ User की एक आवृत्ति से मेल खाती है।

अब जब हमारे पास सुरक्षित पृष्ठ हैं, तो एक SecurityController बनाएं। ऐसा करने के लिए, निम्नलिखित के साथ src / Company / BlogBundle / नियंत्रक निर्देशिका में SecurityController.php फ़ाइल बनाएं:

 namespace Company\BlogBundle\Controller; use Symfony\Bundle\FrameworkBundle\Controller\Controller; use Symfony\Component\Security\Core\SecurityContext; class SecurityController extends Controller { public function loginAction() { if ($this->get('request')->attributes->has(SecurityContext::AUTHENTICATION_ERROR)) { $error = $this->get('request')->attributes->get(SecurityContext::AUTHENTICATION_ERROR); } else { $error = $this->get('request')->getSession()->get(SecurityContext::AUTHENTICATION_ERROR); } return $this->render('BlogBundle:Security:login.html.twig', array( 'last_username' => $this->get('request')->getSession()->get(SecurityContext::LAST_USERNAME), 'error' => $error )); } } 

हमने एक कार्रवाई लॉगिन बनाया है जो _security_login मार्ग से मेल खाता है। इसके अंदर, त्रुटियों के लिए एक चेक किया जाता है और फिर login.html.twig टेम्पलेट को एक उत्तर के रूप में दिया जाता है। त्रुटियों के लिए जाँच करना थोड़ा अजीब लग सकता है, लेकिन वास्तव में हम केवल यह पता लगाने की कोशिश कर रहे हैं कि हम इस कार्रवाई में कैसे शामिल हुए - एक प्रत्यक्ष लिंक के माध्यम से या पुनर्निर्देशित। इसके आधार पर, हमें एक फेंका हुआ अपवाद मिलता है।

सुरक्षा घटक उपयोगकर्ता क्रेडेंशियल्स के सभी सत्यापन का ख्याल रखता है, हालांकि, हमें एक टेम्पलेट बनाना होगा जो कुछ मापदंडों को स्वीकार करता है। सुरक्षा घटक को डेटा को सही ढंग से मान्य करने के लिए, यह आवश्यक है कि फॉर्म में _username और _password फ़ील्ड्स हों , और _security_check मार्ग के लिए भी बाध्य होना चाहिए। इसे src / Company / BlogBunde / Resources / views निर्देशिका में सुरक्षा फ़ोल्डर बनाकर करते हैं, जिसके बदले में, हम निम्नलिखित सामग्री के साथ login.html.twig फ़ाइल बनाते हैं:

 {% extends "BlogBundle::layout.html.twig" %} {% block title %} symfony2  |  {% endblock %} {% block content %} {% if error %} <div class="error">{{ error.message }}</div> {% endif %} <form action="{{ path('_security_check') }}" method="POST"> <table> <tr> <td> <label for="username">:</label> </td> <td> <input type="text" id="username" name="_username" value="{{ last_username }}" /> </td> </tr> <tr> <td> <label for="password">:</label> </td> <td> <input type="password" id="password" name="_password" /> </td> </tr> </table> <input type="submit" name="login" value="" /> </form> {% endblock %} 

यहां सब कुछ स्पष्ट होना चाहिए। फॉर्म से डेटा भेजते समय _security_check मार्ग के साथ, सुरक्षा घटक अनुरोध को रोक देगा और स्वयं को प्रमाणित करेगा। सफल प्रमाणीकरण के बाद, उपयोगकर्ता को मूल पते पर भेज दिया जाएगा, अन्यथा, लॉगिन फ़ॉर्म वाले पृष्ठ पर।

अब एक एग्जिट लिंक बनाते हैं जो केवल लॉग-इन उपयोगकर्ताओं को दिखाया जाएगा। Src / Company / BlogBundle / Resources / views निर्देशिका में लेआउट . html.twig फ़ाइल खोलें और निम्नलिखित परिवर्तन करें:

 // ... {% block body %} <div id="container"> <header class="clearfix"> <h1> symfony2  </h1> <nav> <ul> <li> <a href="{{ path('show_page', { 'page' : 'about' }) }}">   </a> </li> {% if is_granted('IS_AUTHENTICATED_FULLY') %} <li> <a href="{{ path('_security_logout') }}">  </a> </li> {% endif %} </ul> </nav> </header> // ... 

हमने एक विशिष्ट भूमिका निभाने के लिए उपयोगकर्ता का परीक्षण करने के लिए टहनी फ़ंक्शन का उपयोग किया है। हमारे उदाहरण में, यह IS_AUTHENTICATED_FULLY भूमिका है, जो सुरक्षा घटक द्वारा प्रमाणित उपयोगकर्ताओं को सौंपी गई एक विशेष भूमिका है। यदि उपयोगकर्ता की यह भूमिका है, तो नेविगेशन मेनू में ऊपर निर्मित _security_logout मार्ग का लिंक जोड़ें।

अब, सिद्धांत रूप में, हम अपने संरक्षित पृष्ठ का परीक्षण कर सकते हैं, लेकिन इससे पहले, आइए कैश को साफ़ करें। इसके लिए एक कंसोल कमांड है:

 php app/console cache:clear 

अब "/ admin /" पर जाने का प्रयास करें। आपको एक लॉगिन फ़ॉर्म वाले पृष्ठ पर पुनर्निर्देशित किया जाना चाहिए जो कुछ इस तरह दिखता है (विस्तार करने के लिए क्लिक करें):



लॉगिन फ़ील्ड में john.doe टाइप करें और पासवर्ड फ़ील्ड में व्यवस्थापक करें । क्रेडेंशियल्स भेजने के बाद, आपको व्यवस्थापक अनुभाग के मुख्य पृष्ठ पर पुनः निर्देशित किया जाना चाहिए, जो कुछ इस तरह दिखता है (विस्तार करने के लिए क्लिक करें):



नेविगेशन के साथ मेनू में, "बाहर निकलें" लिंक दिखाई देना चाहिए। यदि आप इसके माध्यम से जाते हैं, तो हम आवेदन के मुख्य पृष्ठ पर स्थानांतरित हो जाएंगे, और उसी समय हम लॉग आउट करेंगे। ओह! आपने बहुत अच्छा काम किया है! और मेरे हिस्से के लिए मैंने इस लेख में बहुत प्रयास किया है और परीक्षण और त्रुटि का एक लंबा रास्ता तय किया है! नतीजतन, हमारे पास एक सुरक्षित एप्लिकेशन अनुभाग और संबंधित मार्ग उपसर्ग है (लगभग। - "/ व्यवस्थापक / *")। मैं एक बार फिर दोहराता हूं कि अनुप्रयोगों के उत्पादन संस्करणों में FOSUserBundle का उपयोग करने के लिए दृढ़ता से सिफारिश की जाती है, जो कि इस लेख में हमने जो बनाया है, उससे कहीं अधिक कार्यात्मक है। मुझे उम्मीद है कि सब कुछ स्पष्ट रूप से लिखा गया था, लेकिन अगर कुछ को अतिरिक्त स्पष्टीकरण की आवश्यकता है, तो मुझे बताएं।

अनुवादक से

इस विषय के भाग के रूप में, यह आधिकारिक प्रलेखन के सुरक्षा अनुभाग को पढ़ने के लिए उपयोगी है। विशेष रूप से नोट कुकबुक के लेख हैं: एक्सेस कंट्रोल लिस्ट (एसीएल) और उन्नत एसीएल कॉन्सेप्ट ।

मैं आपके लिए Symfony2 में व्यक्तिगत रूप से क्या था या क्या नहीं है, इसके बारे में जानकारी एकत्र करता हूं, साथ ही Symfony2.0 के बारे में अच्छे लेखों के लिंक (अधिमानतः रूपरेखा जारी होने के बाद लिखे गए)। हम एक साथ सिम्फनी फ्रेमवर्क हबब्लॉग की रेटिंग बढ़ाएंगे!

अनुवाद पर ही शिकायतों और सुझावों की पुस्तक यहाँ है - प्लेसेग । मैं किसी भी प्रतिक्रिया के लिए खुशी होगी!