DEV Community: Locastic

Can you use Sylius to build booking systems?

Locastic — Wed, 25 Aug 2021 12:00:32 +0000

For the last few months, we’ve been working on the MVP for a project similar to the Airbnb booking engine. Even though we were building an MVP, we still wanted to use a top-notch stack, amazingly fast application, and we wanted to reach the market as soon as possible. On the frontend, we are using Next.js with Vercel as hosting, and on the backend side, we are using Sylius as a headless e-commerce solution with our custom dedicated servers.

Was this a good idea, is it even possible? Let’s find out.

Is Sylius ready to be a booking engine?
At the moment, it is probably not ready to be a booking engine, at least not out of the box. But booking engines can be quite similar to e-commerce, and the flexibility of Sylius offers you a way to use it for many different purposes.

Sylius is using ApiPlatform (still a work in progress and in the experimental phase) to provide a headless system. Since our team in Locastic are experts in the entire stack (Symfony, Sylius, ApiPlatform) and since we calculated that we will save some time in getting to the market faster with Sylius – we wanted to give it a try.

Please note that I am not saying that this is the best way for building the booking engine, if you have a huge and complex project, maybe a better solution is to build an entire engine from the scratch or use existing solutions. Also, in this situation, you need to know Sylius and ApiPlatform in the depth, almost every detail and you will have a lot of overhead (features from Sylius that you are not using).

Modeling accommodations a.k.a. SyliusProduct
For this MVP project, the most complex part was modelling Products. Our products are actually Accommodations. Even basic accommodation has:

different attributes (for example pets allowed, has a pool, smoking allowed, free parking on premises, bbq and etc). In general, any amenities are properties in our case and we will use this for searching and filtering accommodations
a different price and availability per date
number of minimal days for booking (min stay)
number of guests, with different settings for children and infants
shipping is not required
Using Sylius Product Attributes
When we are talking about product attributes, we are usually dealing with them in two ways. Adding them in the code (extending Product or ProductVariant entities, forms and etc.), or using built-in Sylius properties. In general, the first way requires a lot of coding but you will maybe gain some performance in searching and managing queries later, so if you have a few properties that are always required, this could be a way to go.

The second way is more flexible and since we already have 100+ Attributes, it was a logical choice for us. Also, we don’t want to spend a few hours/days each time to introduce a new Attribute when this can be added by the Client through the Sylius administration. Each new Attribute that is added is exposed via API to the frontend and it is shown in the filters list as part of the search form.

Since we have a lot of Attributes we don’t want to bother users to search and add them one by one to the Product (current Sylius UX in administration), so we changed the ProductFactory service to add all of the Attributes to each Product/Accommodation. Here is the source code:

<?php

declare(strict_types=1);

namespace App\Factory;

use App\Entity\Product\Product;
use App\Entity\Product\ProductAttributeValue;
use App\Entity\Product\ProductOption;
use App\Repository\Product\ProductOptionRepository;
use Sylius\Component\Product\Factory\ProductFactoryInterface;
use Sylius\Component\Product\Model\ProductInterface;
use Sylius\Component\Resource\Factory\FactoryInterface;
use Sylius\Component\Resource\Repository\RepositoryInterface;
use Webmozart\Assert\Assert;

final class ProductFactory implements ProductFactoryInterface
{
    private ProductFactoryInterface $decoratedFactory;

    private ProductOptionRepository $productOptionRepository;

    private RepositoryInterface $productAttributeRepository;

    private FactoryInterface $productAttributeValueFactory;

    public function __construct(
        ProductFactoryInterface $factory,
        ProductOptionRepository $productOptionRepository,
        RepositoryInterface $productAttributeRepository,
        FactoryInterface $productAttributeValueFactory
    ) {
        $this->decoratedFactory = $factory;
        $this->productOptionRepository = $productOptionRepository;
        $this->productAttributeRepository = $productAttributeRepository;
        $this->productAttributeValueFactory = $productAttributeValueFactory;
    }

    public function createNew(): ProductInterface
    {
        /** @var Product $product */
        $product = $this->decoratedFactory->createNew();

        $optionDate = $this->productOptionRepository->findOneByCode('date');
        Assert::isInstanceOf($optionDate, ProductOption::class);

        $product->addOption($optionDate);

        $attributes = $this->productAttributeRepository->findAll();

        foreach ($attributes as $attribute) {
            /** @var ProductAttributeValue $attributeValue */
            $attributeValue = $this->productAttributeValueFactory->createNew();
            $attributeValue->setAttribute($attribute);
            $product->addAttribute($attributeValue);
        }

        return $product;
    }

    public function createWithVariant(): ProductInterface
    {
        return $this->decoratedFactory->createWithVariant();
    }
}

Since most of these Attributes are true/false, all the user needs to do is to mark the true ones.

Sylius ProductVariants to the rescue
Let’s think a little bit about ProductVariants. In their core definition, they are the same Product but with some different variations, as the name says. In Sylius we can generate ProductVarints from the ProductOption, and out of the box we have the possibility to add different price, different ProductOptionValue, different stock (availability). So it is a perfect match for our Accommodation (Product) which will have different price, availability for each date (ProductVariant).

If you paid attention above to the ProductFactory service, you noticed this line:

$this->productOptionRepository->findOneByCode('date');

So, we created a ProductOption with the code/name ‘date’. Then we assign all the possible values for this Option for example all the dates from today to the +2years (note: don’t do this manually, also you will need to create CronJob that will remove the date in the past and add new dates for example every day). From this option, we can now generate all the required variants.

Shipping is not required, tracking is required
Since we are not shipping any of our products, we have a requirement to mark isShippingRequired as false. We want to be sure that this requirement is always fulfilled, and we don’t want to bother our client with this, so we simply override the method in the ProductVariant.

   // none of items requires shipping, always false
    public function isShippingRequired(): bool
    {
        return false;
    }

A similar thing we did with isTracked method, just we are returning true there. In general, Sylius Admin is not very user friendly for this type of project, since we are managing literally thousands of ProductVariants, so in our case, we removed the entire part of Sylius admin where ProductVariatns are managed, and put all of this in the simple calendar, where user can see price, availability, reservations, can close the dates and etc. Actually, we build a more native and domain friendly UX for this type of project.

With isShippingRequired === false, we are also removing a step with delivery from our checkout process, since we are not shipping anything.

Sylius cart/order modifications for a booking system
I already mentioned how we removed the shipping step from the checkout, in general, if you need any other adjustment you will need to deal with Sylius checkout workflow, also if you are using the APIs the things are slightly different.

What we also did here is allowing only one product (there is almost a 0% chance that someone will book two accommodations at the same time. Since the booking domain is slightly different, we wanted to adjust adding to the cart to the more natural flow. So instead of sending an array of ProductVariant ids, we are sending Product Id and reservation starting and add date. Bellow is part of the code of our AddItemsToCartProcessor that is used inside CommandHander.

<?php

declare(strict_types=1);

namespace App\Order\Processor;

use App\Entity\Order\Order;
use App\Entity\Order\OrderItem;
use App\Entity\Product\Product;
use App\Entity\Product\ProductVariant;
use App\Message\Order\BaseAddItemsToOrderMessage;
use App\Repository\Product\ProductVariantRepository;
use Sylius\Component\Order\Modifier\OrderItemQuantityModifierInterface;
use Sylius\Component\Order\Modifier\OrderModifierInterface;
use Sylius\Component\Order\Processor\OrderProcessorInterface;
use Sylius\Component\Resource\Factory\FactoryInterface;

class AddItemsToCartProcessor
{
    // ...

    public function process(Order $cart, Product $product, BaseAddItemsToOrderMessage $message): Order
    {
        $cart->clearItems();

        $productVariants = $this->productVariantRepository->findAvailableByProductCodeBetweenDates(
            $message->getProductCode(),
            $message->getDateFrom(),
            $message->getDateTo()
        );

        if (empty($productVariants)) {
            return $cart;
        }

        foreach ($productVariants as $productVariant) {
            /** @var OrderItem $cartItem */
            $cartItem = $this->orderItemFactory->createNew();

            /** @var ProductVariant $productVariant */
            $cartItem->setVariant($productVariant);
            $cartItem->setDate($productVariant->getDate());
            $cartItem->setVariantName($productVariant->getName());
            $cartItem->setProductName($productVariant->getProduct()->getName());

            $this->orderItemQuantityModifier->modify($cartItem, 1);
            $this->orderModifier->addToOrder($cart, $cartItem);
        }

        // ... some custom logic ... 

        $this->orderProcessor->process($cart);

        return $cart;
    }
}

Don’t forget to create a custom API endpoint, with a custom message and message handler.

Booking (SyliusOrder) validation
You can notice above that we are not validating our request anywhere, and we should do that. We should validate first basic things, like data received from the application. For basic validation of data, we are using SymfonyValidor, with build validation:

App\Message\Order\AddItemsToOrderMessage:
    constraints:
        - App\Validator\ValidReservationRequest: ~ 
    properties:
        productCode:
            - NotNull: ~
            - NotBlank: ~
        dateFrom:
            - Type: \DateTimeInterface
            - GreaterThanOrEqual: today
        dateTo:
            - Type: \DateTimeInterface
            - GreaterThan:
                  propertyPath: dateFrom
        adults:
            - Type: integer
            - PositiveOrZero: ~
        children:
            - Type: integer
            - PositiveOrZero: ~
        infants:
            - Type: integer
            - PositiveOrZero: ~

Probably you already noticed something not standard-out-of-the box validation here, and yes

   constraints:
        - App\Validator\ValidReservationRequest: ~

is our most important and custom validation. Here we are validating things as product exist, minimal stay, number of guests, number of infants, availability and etc. Of course, this validation can be even more complex, this is depending on your requirements, but this is just an example of what you should have in mind.

<code><?php

declare(strict_types=1);

namespace App\Validator;

use App\Entity\Product\Product;
use App\Message\Order\BaseAddItemsToOrderMessage;
use App\Repository\Product\ProductRepository;
use App\Repository\Product\ProductVariantRepository;
use Symfony\Component\Form\Exception\UnexpectedTypeException;
use Symfony\Component\Validator\Constraint;
use Symfony\Component\Validator\ConstraintValidator;
use Webmozart\Assert\Assert;

class ValidReservationRequestValidator extends ConstraintValidator
{
    private ProductRepository $productRepository;

    private ProductVariantRepository $productVariantRepository;

    public function __construct(
        ProductRepository $productRepository,
        ProductVariantRepository $productVariantRepository
    ) {
        $this->productRepository = $productRepository;
        $this->productVariantRepository = $productVariantRepository;
    }

    public function validate($addItemsToOrderMessage, Constraint $constraint): void
    {
        if (!$constraint instanceof ValidReservationRequest) {
            throw new UnexpectedTypeException($constraint, ValidReservationRequest::class);
        }

        /** @var BaseAddItemsToOrderMessage $addItemsToOrderMessage */
        Assert::isInstanceOf($addItemsToOrderMessage, BaseAddItemsToOrderMessage::class);

        $product = $this->productRepository->findOneByCode($addItemsToOrderMessage->getProductCode());

        // check if product exists
        if (!$product instanceof Product) {
            $this->context->buildViolation($constraint->messageProductNotFound)
                ->addViolation();

            return;
        }

        // check minimal stay requirements
        if ($product->getMinStay() > $addItemsToOrderMessage->getStayLength()) {
            $this->context->buildViolation($constraint->messageMinimalStay)
                ->setParameter('{{ minStay }}', (string) $product->getMinStay())
                ->addViolation();

            return;
        }

        // check number of guests (noOfGuests = adults + children)
        if ($product->getNumberOfGuests() < $addItemsToOrderMessage->getNumberOfGuests()) {
            $this->context->buildViolation($constraint->messageNumberOfGuests)
                ->setParameter('{{ numberOfGuests }}', (string) $product->getNumberOfGuests())
                ->addViolation();

            return;
        }

        // check number if infants
        if ($product->getNumberOfInfants() < $addItemsToOrderMessage->getInfants()) {
            // infants are not allowed
            if ($product->getNumberOfInfants() === 0) {
                $this->context->buildViolation($constraint->messageInfantsNotAllowed)
                    ->addViolation();

                return;
            }

            $this->context->buildViolation($constraint->messageNumberOfInfants)
                ->setParameter('{{ numberOfInfants }}', (string) $product->getNumberOfGuests())
                ->addViolation();

            return;
        }

        // ensure dates are sent without defined time
        if ($addItemsToOrderMessage->getDateFrom() != $addItemsToOrderMessage->getDateFrom()->setTime(0, 0)) {
            $this->context->buildViolation($constraint->messageTimeDefined)
                ->addViolation();

            return;
        }

        if ($addItemsToOrderMessage->getDateTo() != $addItemsToOrderMessage->getDateTo()->setTime(0, 0)) {
            $this->context->buildViolation($constraint->messageTimeDefined)
                ->addViolation();

            return;
        }

        if ($addItemsToOrderMessage->getStayLength() !== $this->getNumberOfAvailableProductVariants($addItemsToOrderMessage)) {
            $this->context->buildViolation($constraint->messageDatesAreNotAvailable)
                ->addViolation();

            return;
        }
    }

    private function getNumberOfAvailableProductVariants(BaseAddItemsToOrderMessage $addItemsToOrderMessage): int
    {
        return count(
            $this->productVariantRepository->findAvailableByProductCodeBetweenDates(
                $addItemsToOrderMessage->getProductCode(),
                $addItemsToOrderMessage->getDateFrom(),
                $addItemsToOrderMessage->getDateTo()
            )
        );
    }
}

So, can Sylius be a booking engine?
Although it would take ages to describe the custom adaptations we did inside this project, it is possible!

Product and ProductVariants can work perfectly to build availability and pricing calendar for accommodations, we can easily remove shipping and add tracking to our ProductVariants, also it is very easy to add custom validation. Yes, you are getting a lot of overhead from Sylius also, the Sylius Admin UX is not the most friendly one for this type of project and etc. It is up to the team to decide if this approach is good for the project or not – but for us, it’s been working like a charm.

Let us know in the comments what do you think about this approach, or drop us an email if you need help with any type of Sylius/Symfony projects.

Quick 7 tips for Symfony starters

Locastic — Fri, 05 Feb 2021 12:32:24 +0000

From a version to another reaching 5.2.1 as the latest stable release, Symfony is scaling to become in line with PHP Framework on the throne.

For all of you that have been living under the rock, Symfony is an Open Source PHP Framework for web applications that thousands of web sites and applications rely on. It’s a set of standalone PHP components that most of the leading PHP projects such as Drupal and Laravel use to build their own applications.

For the past few years, Symfony has been the main backend framework for the majority of Locastic projects so I extracted these quick tips from a perspective of a backender with major experience of working on many projects built on top of this growing framework.

1. Make use of others experience

Nowadays, regarding the COVID-19 pandemic, the migration for e-Commerce platforms seems to be an obligation for too many commercial companies and even for small merchants. Once engaged to develop one of these platforms you definitely should use Sylius since it covers almost all e-commerce features and furthermore it’s an Open-Source headless e-commerce platform built on top of Symfony.

For example, take a look at the TommySpiza project that I contributed to and which uses the full potential of the Sylius platform.

2. You don’t need a shotgun to kill an ant

Many times, Symfony developers use FOSUserBundle in an API context to only store users in a database without using the full potential of this bundle.

This is a bad habit of integrating third-party libraries that come with plenty of features and then use only one between them.

So if you are not willing to use functionalities such as login, registration, reset the password, profile and groups just refer to this guide in order to create your custom authentication system with the guard.

3. Never be afraid to try something new

Often, the first thing that came to a Symfony beginner’s mind is that Symfony is an MVC framework! The good news, this is INCORRECT.

Symfony is never defined as an MVC framework but an HTTP framework

Fabien Potencier
From this basis, try to discover the ADR pattern specified by Paul M. Jones, it will amaze you especially with Symfony’s new features such as Autowiring which is an automatic constructor dependency injection system that reduces the configuration when managing services within the container.
Here’s an example of a Mailer service that needs a Logger to operate :

Classic fashion

# app/config/services.yml services: logger: class: App\Service\Logger mailer: class: App\Service\Mailer arguments: ['@logger']

Magic fashion
# app/config/services.yml services: mailer: class: App\Service\Mailer autowire: true

4. Don’t reinvent the wheel

Surely you’ve heard that while programming it’s discouraged to reinvent the wheel. This really depends on what your aim is. From the perspective of a learning mindset, this seems to be incorrect especially when re-inventing you will learn how solutions are made when resolving problems and you will get a deeper understanding of how they work, but according to a pragmatic mindset, you definitely want to resolve problems at minimal cost and give more importance to the re-use rather than the invention especially when it comes to well-documented existing solutions.

So for example, In order to build a REST API on top of Symfony, you don’t need to spend too much time on purpose. Do it in a faster, cleaner, and more effective way using API Platform Framework, which comes with an easy-to-use and powerful library to create hypermedia-driven REST APIs.

5. Good Developers Write Good Code

The main mission of a software developer is to ship software that works but also which is easily maintainable. To do so, you will usually work with other contributors that may use, maintain or even extend your code so this latter needs to be as clean and understandable as possible to ensure productivity and efficiency. Good code is subjective, so try on building the best code possible. In my opinion, to be a good Symfony developer you must first be able to write good code. For such a purpose try to learn Coding Standards.

6. Think twice, code once, but always test!

There is a knock on the Symfony framework that it is slow when building applications that consume a huge amount of data. So, if you once need to store for example 10.000 records at the same time, you need to figure out how to do it without affecting performance. Batch processing is the best solution for such a use case, just have a look at the bunch of code below.

$batchSize = 20; for ($i = 1; $i <= 10000; ++$i) { $symfonista = new Symfonista; $symfonista->setStatus('newbie'); $symfonista->setUsername('symfonista' . $i);

$em->persist($symfonista);

if (($i % $batchSize) === 0) { $em->flush(); $em->clear(); // Detaches all objects from Doctrine! } } $em->flush(); //Persist objects that did not make up an entire batch $em->clear();

This seems to be cool at the first sight, but be careful every new line of code you write is potentially adding new bugs, so don’t forget to write your functional and unit tests.

// inside TestCase class $entityManagerMock = $this ->getMockBuilder('Doctrine\ORM\EntityManager') ->disableOriginalConstructor() ->getMock(); $entityManagerMock ->expects($this->any()) ->method('persist') ->will($this->returnValue(true)); $entityManagerMock ->expects($this->any()) ->method('flush') ->will($this->returnValue(true)); $entityManagerMock ->expects($this->any()) ->method('clear') ->will($this->returnValue(true));

7. Ask an experimenter, don’t ask the doctor

Let’s say you are building a feature estimate. As a junior, no one expects that you know exact numbers, but you can always use the cautious approach – whatever your estimate is, double it! Be careful because there will always be some secret failures inside hidden functionalities you develop and that you should take care of eventually.

Who knows, maybe I’m the experimenter you’d be looking for?
Get in touch if you’re ready to start your Symfony journey or share this article on social media and I’ll jump in for a further discussion.

Administrate your administrators with Sylius RBAC

Locastic — Mon, 18 Jan 2021 07:08:28 +0000

Not long ago, we went through a common, yet complicated demand on a Sylius shop : “ Contextualize access rights according to the admin user logged in“

At the moment, there are 2 solutions to do so in the Sylius Ecosystem.

The one that comes with SyliusPlus and that I yet have to try.
And the one from BitBag Plugin, that I also have not tried yet.
But since that for the purpose of the project, we needed a very basic feature, and we did not want to bother understanding and overriding any of those two existing (and paid) solutions, we decided to use a custom one.

Concept

We chose a role-based approach, with a grant/deny strategy. As a matter of fact, it is quite similar to the one that Symfony offers out of the box with the security component. So the first step was to define the data structure. We opted in for YAML defined roles, because at first, the roles should only be manageable via the code, but can then be deported to the admin panel. And since YAML is easily convertible to PHP array, it sounded like the top choice for this task.

Data structure

<code>parameters: roles_accesses: {roleName}: strategy: 'denyAllExcept' redirect_if_not_granted: 'sylius_admin_dashboard' allow_partials: true exceptions: routes: - 'sylius_admin_dashboard' - 'sylius_admin_taxon_*' resources: - 'sylius.product.index' abstain_for: routes: - 'sylius_admin_admin_user_update' resources: - 'sylius.admin_user.update'

Here is the structure we are using. It is a simple Symfony parameter, since we went with a denyAllExcept strategy, all the routes or resources in exceptions are allowed. We also decided to allow all partial routes at once since a lot of admin pages rely on those (product autocomplete ie.). Regarding the abstain_for part, we will get back to that later.

Get the file and deny access

Let’s now use this new parameter in our app. And to do so, we will use a leftover from old Sylius versions that were never removed, fortunately.

In each and every ResourceController there is a check in the form of $this->isGrantedOr403(). And if we dig a little bit more, it is calling a DisabledAuthorizationChecker that always return true. Obviously, this is not useful at all like that, but the main point is that Sylius is giving us a way to develop that, without much effort.

We have to create a new class that implements this AuthorizationCheckerInterface from SyliusResourceBundle.

But things would be too easy if that was it, wouldn’t they?

<?php declare(strict_types=1); namespace App\RightsManagement\Controller; use App\RightsManagement\Exception\AdminUserAccessDeniedException; use App\RightsManagement\Provider\ResourceProviderInterface; use App\RightsManagement\Security\AdminAuthorizationCheckerInterface; use Sylius\Bundle\ResourceBundle\Controller\AuthorizationCheckerInterface; use Sylius\Bundle\ResourceBundle\Controller\RequestConfiguration; final class AuthorizationChecker implements AuthorizationCheckerInterface { private AdminAuthorizationCheckerInterface $adminAuthChecker; private ResourceProviderInterface $resourceProvider; public function __construct( AdminAuthorizationCheckerInterface $adminAuthChecker, ResourceProviderInterface $resourceProvider ) { $this->adminAuthChecker = $adminAuthChecker; $this->resourceProvider = $resourceProvider; } public function isGranted(RequestConfiguration $configuration, string $permission): bool { $request = $configuration->getRequest(); $routeName = $request->attributes->get('_route'); $resource = $this->resourceProvider->getFromPermissionAndRequestConfiguration($permission, $configuration); if (!$this->adminAuthChecker->isGranted($routeName, $permission, $resource)) { throw new AdminUserAccessDeniedException('You shall not pass'); } return true; } }

So here, we are performing a few basic, but needed tasks for our feature.

First of all, we fetch the route name. It will be useful later to perform checks on it.

Secondly, we fetch the resource concerned by the action. Without going into details, it will fetch the resource in case of update, delete or show and null for other cases. The third and final action is to perform a check against a Voter with permission, the resource, and the route.

Voting is a duty

Regarding the voter implementation its role will be to first filter the strictly granted or denied routes. You know, those in exceptions . Will they be routes, or resources.

public function isGranted(?string $routeName, ?string $permission, ?ResourceInterface $resource = null): bool { if (null !== $routeName) { $routeVoter = new RouteVoter($this->adminUserRightsProvider); $routeDecision = $routeVoter->vote($this->tokenStorage->getToken(), $routeName, [RouteVoter::ACCESS_ROUTE]); if (VoterInterface::ACCESS_DENIED === $routeDecision) { return false; } elseif (VoterInterface::ACCESS_GRANTED === $routeDecision) { return true; } } if (null !== $permission) { // Determine requested access type $accessType = $this->getResourceAccessType($permission); if (null === $accessType) { return true; } $resourceVoter = new ResourceVoter($this->adminUserRightsProvider); $resourceDecision = $resourceVoter->vote($this->tokenStorage->getToken(), $permission, [$accessType]); if (VoterInterface::ACCESS_DENIED === $resourceDecision) { return false; } elseif (VoterInterface::ACCESS_GRANTED === $resourceDecision) { return true; } // Try to call Symfony voter return $this->authorizationChecker->isGranted($permission, $resource); } return true; } private function getResourceAccessType(string $permission): ?string { $type = null; if (\preg_match('/\.([a-z]+)$/', $permission, $matches)) { $type = $matches[1]; } switch ($type) { case ResourceActions::INDEX: return ResourceVoter::LIST_RESOURCES; case ResourceActions::UPDATE: return ResourceVoter::UPDATE_RESOURCE; case ResourceActions::CREATE: return ResourceVoter::CREATE_RESOURCE; case ResourceActions::SHOW: return ResourceVoter::SHOW_RESOURCE; case ResourceActions::DELETE: return ResourceVoter::DELETE_RESOURCE; default: return null; } }

Here is an example of how to do it, but of course there are many other ways. Once more, // TODO

Once this filter is done, if we are still there, and no boolean has been returned, we are left with the abstain_for. Meaning another voter should now be asked to vote for this access.

And here comes the SymfonyVoter. The idea here will be to be able to grant access to a resource according to some specifications. Like an admin can edit his profile, but can not edit other admin.

And since we managed to fetch the resource earlier, it is easy to compare according to custom logic. Here is an example.

<?php declare(strict_types=1); namespace App\RightsManagement\Security\Voter\User; use App\Entity\User\AdminUser; use LogicException; use Symfony\Component\Security\Core\Authentication\Token\TokenInterface; use Symfony\Component\Security\Core\Authorization\Voter\Voter; use function in_array; final class AdminUserVoter extends Voter { public const UPDATE = 'sylius.admin_user.update'; /** * @param string $attribute * @param mixed $subject * * @return bool */ protected function supports($attribute, $subject): bool { if (!in_array($attribute, [self::UPDATE])) { return false; } if (!$subject instanceof AdminUser) { return false; } return true; } protected function voteOnAttribute($attribute, $subject, TokenInterface $token): bool { $loggedInUser = $token->getUser(); if (!$loggedInUser instanceof AdminUser) { return false; } if ($loggedInUser->getGroup() === AdminUser::GROUP_SUPER_ADMIN) { return true; } /** @var AdminUser $subjectUser */ $subjectUser = $subject; switch ($attribute) { case self::UPDATE: return $this->canUpdate($subjectUser, $loggedInUser); } throw new LogicException('This code should not be reached.'); } private function canUpdate(AdminUser $subject, AdminUser $loggedInUser): bool { // Non admin user can only update themselves return $subject->getId() === $loggedInUser->getId(); } }

And there you go! That means that our new role can perform taxon management, can list products, and edit his profile. Everything else will be forbidden.

Starting from that, you can easily do any custom mechanism you want inside your Sylius App.

"What about you?
How are you managing roles inside your application? Feel free to share the article on social media and I’ll join the discussion!

Bulletproof static code analysis for React

Locastic — Mon, 26 Oct 2020 09:03:52 +0000

First of all, let’s clarify what even is static code analysis.

Wikipedia says:

Static program analysis is the analysis of computer software that is performed without actually executing programs, in contrast with dynamic analysis, which is analysis performed on programs while they are executing. In most cases the analysis is performed on some version of the source code, and in the other cases, some form of the object code.”

In other words, static analysis simply parse the code you wrote, validate it against the rules you defined, and gives you immediate feedback whether or not your code meets defined requirements (typos and type errors while you write the code)

I like the opinion that static code analysis is the first and lowest level of the testing pyramid. Unlike more advanced levels of testing like integration or unit testing, static analysis can be performed against the code without actually running it (no servers or build processes). That alone makes it the fastest and simplest testing tool.

https://testingjavascript.com/
The way it works is quite simple:

compiler finishes the “static analysis” phase
product is the AST (Abstract syntax tree)
the tree gets traversed and validated against the defined rules

Static analysis for React

There are two things I set up by default on every React project I work on:

ES Lint – code linter for enforcing certain code style
Prettier – code formatting tool

ES Lint is probably one tool you always want to have present in the codebase. It analyzes the code and quickly finds problems. The fixes it provides are syntax aware which means it will not cause funky bugs. And the best part – you can adjust it according to your needs, which means it’s fully customizable. You can define the set of rules, extend some popular set of rules, etc.

Pettier on the other hand is used to ensure you have consistent code style trough out the project without having to worry different team members will commit different code styles to the codebase. For example, you want the same indentation, line length, single or double quotes, etc.

Setup

npm install --save-dev eslint prettier

In order for Prettier to work with ES Lint, prettier-plugin needs to be installed as well:

npm install --save eslint-plugin-prettier

ES Lint configuration
To configure the ES Lint we can use .eslintrc, a file which would look something like this:

{ "env": { "browser": true, "es6": true }, "parser": "babel-eslint", "extends": ["airbnb", "prettier", "prettier/react"], "globals": { "Atomics": "readonly", "SharedArrayBuffer": "readonly" }, "parserOptions": { "ecmaFeatures": { "jsx": true, "modules": true }, "ecmaVersion": 2018, "sourceType": "module" }, "plugins": ["react", "prettier"], "rules": { "prettier/prettier": "error", "react/jsx-filename-extension": [1, { "extensions": [".js", ".jsx"] }], "react/forbid-prop-types": [0, { "forbid": ["any"] }], "react/prop-types": 0, "react/destructuring-assignment": 0, "react/sort-comp": 0, "react/no-did-update-set-state": 0, "react/jsx-boolean-value": 0, "prefer-template": 1, "prefer-const": 1, "no-unused-vars": 1, "import/prefer-default-export": 1, "import/no-extraneous-dependencies": 1, "import/no-unresolved": 1 } }

Using this file, everything is configurable. Under the rules key, we can change the certain rule to display as a warning, error, or not display at all (disable it). The pluginskey is used to define the set of plugins we want to use (notice the “prettier” plugin we installed before). If you’d like to extend some popular set of ES Lint rules, let’s say Airbnb’s one, you can do that under the extends key. You can find more about configuring the ES Lint on the https://eslint.org/.

Now the linter is all set up, how to run it?

You can add the following lines to you package.json scripts:

"scripts": { "lint" : "eslint ." //to lint all files "lint:fix" : "eslint --fix", //to fix all eslint errors }

If you’re using the VS Code you can install the ES Lint plugin for it (probably other code editors have it too ).

The files you don’t want to lint you can ignore using .eslintignore:

dist
node_modules
public

Prettier configuration

It’s worth to mention that Prettier is not as configurable as ES Lint, but it really has all you need for code formatting. We can use .prettierrc file to configure it:

{- "printWidth": 80, "tabWidth": 2, "useTabs": true, "semi": true, "singleQuote": true, "trailingComma": "none", "bracketSpacing": true, "newline-before-return": true, "no-duplicate-variable": [true, "check-parameters"], "no-var-keyword": true, "arrowParens": "avoid", }

You can find full set of options available on the https://prettier.io/docs/en/options.html

Again, if you are using VS Code there is a Prettier plugin available to install but there are also commands to run the code formatting manually:
//package.json
"scripts": { "prettier": "prettier --check", "prettier:fix": "prettier --write"

For ignoring certain files you can use .prettierignore file (in the same way like .eslintignore).

And there you go. Everything is set up, you are good to start coding with confidence the ES Lint gives you by checking you don’t make silly mistakes like redeclaring the same variable, not closing bracket, or using something that doesn’t exist, while Prettier will make sure your code is readable and consistent trough out the whole project.

Bonus

There is one more thing I like to add to make sure the code with limiting errors and unformatted code cannot be committed to the version control provider at all. It’s the Husky, git hooks tool that allows you to run the scripts before commit, push, etc. Let’s take it a bit further with Lint Staged which allows us to check only staged files. The configuration goes like this:

First, installation:

npm install --save-dev husky lint-staged

Second, package.json:

"lint-staged": { "*.+(js|jsx)": [ "eslint --fix", ], ".+(json|css|md)": [ "prettier --write", ] }, "husky": { "hooks": { "pre-commit": "lint-staged"

That’s it. Now every time the code is committed hook will execute, validate the files you want to commit and either fix the errors for you or warn you there is some error that can’t be auto fixed.

React Native cookie-based authentication

Locastic — Mon, 03 Aug 2020 08:11:37 +0000

User authentication is a single-handedly most required feature when building a modern web or mobile apps. It allows verifying users, user sessions, and most importantly it provides the base for implementing user authorization (roles and permissions).

Basically, you develop a login screen and allow the user to input their username/email and appropriate password and send a request to the server. If the server responds positively, that's it. Your user is logged in. But server returned one more thing: some kind of user identification you need to pass together with other requests to access certain data etc. Also, when the user closes the app without logging out, thanks to this we can keep him logged in and skip the login step every time the user opens the app.

It is either token-based authentication or session-based authentication. This diagram describes the main differences between the two:

Chart credit: https://dzone.com/articles/cookies-vs-tokens-the-definitive-guide

As you can see, in cookie-based authentication, after successful login, the server creates the session and return sessionId value as Cookie. Subsequent requests contain that cookie with sessionId which is verified against sessionId on the server to determine if the session is valid.

On the other hand, we have token-based authentication. After successful login server returns signed token. That token is then usually stored in local storage. Subsequent requests are sent together with the saved token in the Authorization header. The server decodes token and if it is valid, process the request.

Without further due, like the title states - this article will go through cookie-based authentication in React Native because it is not as straightforward as you may think.

The Problem

As you know, React Native relies on the native (Android and iOS) APIs written in Java and Objective-C. You may think the cookie usage is as straightforward as using it within the browser but unfortunately, it isn't.

Native networking APIs are saving the cookies by default and it may seem perfectly okay at the beginning, but after some time and few requests made, requests can become inconsistent causing the server to deny the access because the cookies we sent were invalid even though there is nothing wrong with them when they initially were passed along the request.

The Solution

The first thing that came to my mind is to take the cookie management in to my own hands by simply storing them on the device (eg. Async Storage)

Now the flow goes like this:

after successful login, the server responds with the status and cookies
cookies are saved on the device (Async Storage)
each subsequent request's Header is populated with the cookie from device storage

And I thought this is the final solution. EZ right? But let's see what the flow really looks like now:

It was working fine for a while but then the same problems started to occur and I was at the starting point again. As mentioned above, React Native has its own cookie management and now I implemented my own on top of it. Naturally, native API interfered with my implementation and won every time, overriding the cookie I sent with its own and causing the same problems to appear.

NOTE: I'm not 100% sure yet this is what is happening on the native side.

After some research, I stumbled on the react-native-cookies. It's a cookie management library for React Native and lets you manage cookies natively. Now there is actually a way to manipulate native cookie management, the approach with storing the cookie on the device can be further improved.

As already mentioned, native cookie management interfered with the stored cookies. So let's completely remove native cookies and work just with the ones stored on the device. The easiest way would be to just clean up the cookies stored natively.

That's where the above-mentioned library comes into play:

import CookieManager from 'react-native-cookies'
import AsyncStorage from '@react-native-community/async-storage';

const client = async () => {
    await CookieManager.clearAll() //clearing cookies stored 
                                       //natively before each 
                                       //request
    const cookie = await AsyncStorage.getItem('cookie')
    return await fetch('api/data', {
        headers: {
            'cookie': cookie
        }
    })
}

With natively stored cookies cleaned up before each request, it's certain that the only cookies that are passed along the request are the ones stored manually on the device. Using this simple fix there are no more cookies interfering with each other and the main benefit is consistent sessions while using the app.

Wrap up

I spent a significant amount on time wrestling with this issue because it wasn't so straight forward to figure out what seems to be the problem. I decided to write it down so you don't have to.

I think it's worth mentioning to say this is not the only possible solution to this problem because the problem itself is not fully investigated. There are also solutions without using any library which is described in this article.