…2nd argument to CustomCredentials. For us, that's the submitted password: Let's pretend that all users have the same password tada! To validate that, return true if $credentials === 'tada': Air-tight security! If we return true from this function, authentication is successful! Woo…

…get our first look at authorization. That's the fun part where we get to run around and deny access to different parts of our site. The easiest way to kick someone out of your party is actually right inside of config/packages/security.yaml…

…simple. We need to read the submitted email, query the database for that User object... and eventually check the user's password. The weird thing about Symfony's security system is that... we're not going to write this logic in the controller. Nope. When…

…At the start of every request, before Symfony calls the controller, the security system executes a set of "authenticators". The job of each authenticator is to look at the request, see if there is any authentication information that it understands - like a submitted email and…

…since we want to really learn security, let's do this step-by-step... mostly by hand. Before we start thinking about authenticating the user, we first need to build a login page, which... if you think about it... has nothing to do with security…

…uploaded article images? The first question to ask is: can these uploaded files be public to everyone? Or do we need to do some sort of security check before a user can view or download them? For article images, they can be public. But we…

…barkbite.com, password woof. And when we submit... access denied! No worries: click down on the web debug toolbar's security icon... and go to "Access Decision". Yup: we were denied access because it was looking for a role called ROLE_NGLAYOUTS_ADMIN. To access…

…bin/console commands. Run php bin/console and look for the make section. Ooh. There's a ton of stuff here for setting up security, generating doctrine entities for the database (which we'll do in the next tutorial), making a CRUD, and much more…

…of a CRUD section as a whole. In that case, instead of trying to set permissions on every action like this, you can be lazy and use normal security. For example, head to the top of QuestionCrudController. Above the class, leverage the #[IsGranted] attribute from…

…some users the superpower to temporarily log in as someone else. Here's how. First, we need to enable the feature. In security.yaml, under our firewall somewhere, add switch_user: true: This activates a new authenticator. So we now have our CustomAuthenticator, form_login…

…can configure this. Remember: to get this config, I ran debug:config security... which shows your current configuration, including defaults. But not all options are shown here. To see a full list, run config:dump security. Instead of showing your actual config, this shows a…

…log out link. Access was granted for all three of these. In addition to IS_AUTHENTICATED_FULLY, there are a couple of other special strings that you can pass into the security system. The first is IS_AUTHENTICATED_REMEMBERED, which is super powerful... but can…

…Yup, we have ROLE_USER. This is too boring... so let's add some true admin users! First, open config/packages/security.yaml... and, down under access_control, change this to once again require ROLE_ADMIN: Remember: roles are just strings that we invent... they…

…is kinda cool. If a listener to kernel.request somehow already has enough information to return a response... it can do that! It's not super common, it could be used for security or a maintenance page... but hey! Let's try it ourselves! In…

…of the package... and then each package can have different recipes for different versions. Our recipe lives in sensiolabs/security-checker/4.0. Every recipe has at least this manifest.json file, which describes all of the "things" it should do. This copy-from-recipe…

…First, it deserializes the JSON into whatever resource object we're working with - like a CheeseListing object. Second, it applies the security access controls. And third it applies our validation rules. Do you see the problem? It's subtle. If API Platform has any problems…

…we would grab the email, grab the password and do some magic. Well... we are not going to do that. Symfony's security works in a bit of a "magical" way, at least, it feels like magic at first. At the beginning of every request…

…to app_login and the method to login(): We don't need to pass any variables yet, and we'll call the template login.html.twig: Next, down in templates/security, rename index.html.twig to login.html.twig. Let's try it! Move over…

…token to our server. If that submit happens over a non-https connection, that's a security risk: there could be somebody in the middle reading that token. Regardless of what they might or might not be able to do with that, we need to…

…that can be used to activate development settings locally. But first, we need to play with permissions: Drupal makes some files in this directory readonly for security. Start by making sites/default writable by us: Now, copy sites/example.settings.local.php to sites/default…