Add the following to your vsftpd.conf
file :
tcp_wrappers=YES
Restart vsftpd.
Answer is simple – Security! Alternatives include storing private keys directly on a workstation – which makes them poorly protected in multitude of attacks. A better option is to use encrypted usb key but leaving inserted and unsealed usb key for a long time is insecure, while inserting it and removing it back and forth all the time is tedious.
YubiKey suits much better for this purpose by making your SSH keys much more secure while maintaining a great user experience.
YubiKey is a hardware security key which provides Universal 2nd Factor (U2F) cryptographic tokens through a USB and/or NFC interface. This means you have to explicitly authorize a new SSH session by tapping the YubiKey. The private SSH key should be useless to a malicious user who does not have access to the physical YubiKey on which the second private key is stored.
Interestingly I didn't find a clean and fast solution for database logging for Symfony. There's a monolog-mysql handler on GitHub - sadly it's triggering some errors (not just in Silex, also in Symfony). Luckily Symfony and Monolog make implementing it ourselves quite easy.
The first thing we need is an entity for the log entries.
// src/AppBundle/Entity/Log.php
namespace AppBundle\Entity;
Doctrine offers very powerful API for getting entity properties that have changed. This can be achieved using Doctrine\ORM\UnitOfWork. We can call:
Doctrine\ORM\UnitOfWork::computeChangeSets()
to compute all the changes that have been done to entities and collections and store these changes;Doctrine\ORM\UnitOfWork::getEntityChangeSet($entity)
to retrieve all changes to our entity object;Doctrine\ORM\UnitOfWork::getOriginalEntityData($entity)
to retrieve the original data of an entity before introduced changes.This simple example will explain it:
// find entity
$post = $em->find('Entity\Post', 1);
// change property value
First, after successful authorization - login call returned the JWT token it has to be stored into some variable. When editing login request, there is a "Tests" tab. Here we can put JavaScript code that will be executed after request is executed, so we will enter the code like this there:
var jsonData = JSON.parse(responseBody);
if(jsonData.token) {
pm.globals.set("jwt-token", jsonData.token);
}
Or, shorter version:
pm.globals.set("jwt-token", pm.response.json().token)
You can bring back the old SSL options in 8.0.27:
>2|Require,3|Require and Verify CA,4|Require and Verify Identity
with: >0|No,1|If available,2|Require,3|Require and Verify CA,4|Require and Verify Identity
Source: https://gnugat.github.io/2016/04/20/super-speed-sf-nginx.html
HTTP frameworks, such as Symfony, allow us to build applications that have the potential to achieve Super Speed.
We've already seen a first way to do so (by turning it into a HTTP server), another way would be to put a reverse proxy in front of it.
In this article we'll take a Symfony application and demonstrate how to do so using nginx.
Note: those two ways can be combined, or used independently.
Here are few tips on how to setup Sentry and Symfony integration in more meaningful way from the very beginning.
First of all install Sentry.io integration with Symfony composer require "sentry/sentry-symfony":"3.4.3"
Make sure you have SENTRY_DSN and SENTRY_ENVIRONMENT in all .env files, such as .env.dist, .env.test and so on. SENTRY_DSN is telling our Sentry integration where to connect and oush our log entries and is coming from default installation. SENTRY_ENVIRONMENT on other hand is something we added ourselve, just to be able to distinguish from what type of environment our logs are comming from.
SENTRY_DSN= SENTRY_ENVIRONMENT=dev
Now in monolog configuration config/packages/dev/monolog.yaml add new handler and new parameter, make sure you have added it to all the configs you want it to be.