[FrameworkBundle][Serializer] Add an ArgumentResolver to deserialize & validate user input #45628

GaryPEGEOT · 2022-03-03T20:13:14Z

Q	A
Branch?	6.1
Bug fix?	no
New feature?	yes
Deprecations?	no
Tickets	N/A
License	MIT
Doc PR	TODO

Assuming you wish to validate some DTO:

<?php

use Symfony\Component\Validator\Constraints as Assert;

class DummyDto
{
    #[Assert\NotBlank()]
    public ?string $randomText = null;

    #[Assert\IsTrue()]
    public bool $itMustBeTrue = true;
}

If you're not using API Platform, you will probably have to inject serializer & validator in your controller, check if input can be normalized & is valid:

// Before
public function __invoke(Request $request): Response
{
        $input = $this->serializer->deserialize($request->getContent(), DummyDto::class, 'json');
        $errors = $this->validator->validate($input);

        if ($errors->count()) {
            // Some logic to return error to user
        }

While this not the end of the world (:crossed_fingers:), It can be cumbersome and doesn't necessarily bring value.

Using Symfony\Component\Serializer\Annotation\Input provide an opt'in way to get a DTO deserialized and validated directly in the controller:

// After

use Symfony\Component\Serializer\Annotation\Input;

public function __invoke(#[Input()] DummyDto $input): Response
{
        // do your logic

In case the value is not valid, user will receive a HTTP 422 response. Once again, it's completely opt'in (For those of you who don't like magic 🦄 )

Nyholm

I like this feature. I have some small comments I need help to understand.

src/Symfony/Bundle/FrameworkBundle/EventListener/InputValidationFailedExceptionListener.php

mathsunn · 2022-03-03T21:36:16Z

Nice feature ! Thanks

derrabus · 2022-03-03T21:49:42Z

I like the basic idea of this feature, thank you for the PR. I however believe that it should be implemented differently.

First of all, the marker interface. In a world with native attributes, we should not use marker interfaces anymore. Also, it does not really make sense to add a marker (interface or attribute) to a DTO class just because in some controller I might want to deserialize a request payload into it. If we assume that such a DTO class could be a Doctrine entity at the same time, the current implementation would create unpleasant ambiguites with good old param converters or its replacement (see #43854).

I strongly advice to implement this as an attribute for controller parameters. This would also solve the configuration issues mentioned.

Secondly, I'd like to move as little logic as possible into the framework bundle. I believe this argument resolver should live inside the serializer component and validation should be made optional.

derrabus · 2022-03-03T21:53:19Z

src/Symfony/Bundle/FrameworkBundle/ArgumentResolver/UserInputResolver.php

+    public function resolve(Request $request, ArgumentMetadata $argument): iterable
+    {
+        try {
+            $input = $this->serializer->deserialize($request->getContent(), $argument->getType(), $request->attributes->get('_format', 'json'));


Are we sure the request payload is JSON? Should we check the content type? Should we allow the controller to configure the expected format?

derrabus · 2022-03-03T21:54:02Z

src/Symfony/Bundle/FrameworkBundle/ArgumentResolver/UserInputResolver.php

+        try {
+            $input = $this->serializer->deserialize($request->getContent(), $argument->getType(), $request->attributes->get('_format', 'json'));
+        } catch (ExceptionInterface $exception) {
+            throw new UnparsableInputException($exception->getMessage(), 0, $exception);


Why not UnprocessableEntityHttpException?

derrabus · 2022-03-03T21:56:46Z

src/Symfony/Bundle/FrameworkBundle/EventListener/InputValidationFailedExceptionListener.php

+                ];
+                $reason .= "{$violation->getPropertyPath()}: {$violation->getMessage()} ";
+            }
+            $response = new Response($this->serializer->serialize($data, $format), Response::HTTP_UNPROCESSABLE_ENTITY);


The serializer is capable of rendering a constraint violation list. Why are we inventing a new output format here?

lyrixx

I totally agree with @derrabus 👍🏼

lyrixx · 2022-03-04T08:38:22Z

src/Symfony/Bundle/FrameworkBundle/EventListener/InputValidationFailedExceptionListener.php

+            foreach ($throwable->getViolations() as $violation) {
+                $data['errors'][] = [
+                    'propertyPath' => $violation->getPropertyPath(),
+                    'message' => $violation->getMessage(),
+                    'code' => $violation->getCode(),
+                ];
+                $reason .= "{$violation->getPropertyPath()}: {$violation->getMessage()} ";


You can re-use the https://github.com/symfony/symfony/blob/6.1/src/Symfony/Component/Serializer/Normalizer/ConstraintViolationListNormalizer.php

lyrixx · 2022-03-04T08:39:18Z

src/Symfony/Bundle/FrameworkBundle/ArgumentResolver/UserInputResolver.php

+    public function resolve(Request $request, ArgumentMetadata $argument): iterable
+    {
+        try {
+            $input = $this->serializer->deserialize($request->getContent(), $argument->getType(), $request->attributes->get('_format', 'json'));


Can you also enable the support for type property?

Not sure what you mean by that 😄

https://symfony.com/blog/new-in-symfony-5-4-serializer-improvements#collect-denormalization-type-errors

Nice! thanks, I'll add that

GaryPEGEOT · 2022-03-05T09:29:49Z

src/Symfony/Component/Serializer/EventListener/InputValidationFailedExceptionListener.php

+        }
+
+        $response = new Response($this->serializer->serialize($throwable->getViolations(), $format), Response::HTTP_UNPROCESSABLE_ENTITY);
+        $this->logger->info('Invalid input rejected: "{reason}"', ['reason' => (string) $throwable->getViolations()]);


Not super sure what to log here, as violations might contain sensitive information?

IMHO, the reasons are not really useful in the log

GaryPEGEOT · 2022-03-05T09:35:59Z

@derrabus I switched to Attribute, way nicer indeed, thanks. Not sure about the optional validation though, for two reasons:

It imply to create custom normalization for PartialDenormalizationException instead of relying on ConstraintViolationListNormalizer
Not sure if it's a good practice to "not validate" user data.

And either way, If a dev really don't care about validation, adding no assertion should result in little overhead.

src/Symfony/Component/Serializer/Annotation/Input.php

derrabus · 2022-03-06T16:56:53Z

src/Symfony/Component/Serializer/EventListener/InputValidationFailedExceptionListener.php

+        $throwable = $event->getThrowable();
+        $format = $event->getRequest()->attributes->get('_format', 'json');
+
+        if (!$throwable instanceof ValidationFailedException) {


This change is potentially dangerous. Existing application might already use this exception and your listener will add unexpected sematics to it.

Fixed! Validation is now optional as well

derrabus · 2022-03-06T17:03:23Z

Not sure if it's a good practice to "not validate" user data.

No, but Symfony's validator is certainly not the only tool for that. If we add this functionality to the serializer component (which can even be used standalone), the validator should not be a mandatory dependency for using it.

And either way, If a dev really don't care about validation, adding no assertion should result in little overhead.

Sure, but installing the validator although it's not used actually is unnecessary overhead.

yceruto

I like the idea too, but I think the implementation of the error response should be improved and adapted to use the current ErrorRenderer mechanism.

yceruto · 2022-03-07T03:00:47Z

src/Symfony/Component/Serializer/ArgumentResolver/UserInputResolver.php

+        $context = array_merge($attribute->serializationContext, [
+            DenormalizerInterface::COLLECT_DENORMALIZATION_ERRORS => true,
+        ]);
+        $format = $attribute->format ?? $request->attributes->get('_format', 'json');


Use $request->getPreferredFormat('json') instead (it will take into account the acceptable content type when provided)

Neither is correct, imho. getPreferredFormat() as well as the _format attribute hint at the format of the response. What we need here is the format of the request payload. This can be inferred from the Content-Type header of the request.

That being said, the developer should be able to limit the set of possible formats (and content types?) via the attribute. Maybe we should even default to JSON-only, so nobody enables CSV deserialization by accident. 😓

You're right, then we should use $request->getContentType() instead.

[Off topic] Btw, the name of this method is not exactly what you'd expect here, it returns json, xml, etc. even if that's what we want here it seems like the expected result (according to the method name) is application/json, etc. maybe this method should be renamed to getContentTypeFormat() or something like this, but that's another topic :)

yceruto · 2022-03-07T03:06:28Z

src/Symfony/Bundle/FrameworkBundle/CHANGELOG.md

@@ -8,6 +8,7 @@ CHANGELOG
 * Load PHP configuration files by default in the `MicroKernelTrait`
 * Add `cache:pool:invalidate-tags` command
 * Add `xliff` support in addition to `xlf` for `XliffFileDumper`
+ * Add an ArgumentResolver to deserialize & validate user input


Can you add the specific class(es) added?

This changelog belongs to the Serializer component now, right?

I have to move that 😅

yceruto · 2022-03-07T04:40:41Z

src/Symfony/Component/Serializer/ArgumentResolver/UserInputResolver.php

+
+            $errors = new ConstraintViolationList();
+
+            foreach ($e->getErrors() as $exception) {


I don't think it's the argument resolver's responsibility to normalize these errors, but the Serializer normalizers instead.

In order not to depend on the Validator component (as I've pointed out in another comment) you can add a new PartialDenormalizationProblemNormalizer just to handle this kind of exception.

yceruto · 2022-03-07T04:43:07Z

src/Symfony/Component/Serializer/ArgumentResolver/UserInputResolver.php

+            $input = $this->serializer->deserialize(data: $request->getContent(), type: $argument->getType(), format: $format, context: $context);
+        } catch (PartialDenormalizationException $e) {
+            if (null === $this->validator) {
+                throw new UnprocessableEntityHttpException(message: $e->getMessage(), previous: $e);


This will show an empty message which is not useful. However, we can still normalize the PartialDenormalizationException to show all errors. I mean, it shouldn't depend exclusively on the Validator ConstraintViolationList as it's optional.

yceruto · 2022-03-07T05:14:44Z

src/Symfony/Component/Serializer/EventListener/InputValidationFailedExceptionListener.php

+ *
+ * @author Gary PEGEOT <garypegeot@gmail.com>
+ */
+class InputValidationFailedExceptionListener


I don't think this listener is really necessary to return the proper response (content + status code). Instead, you can go through the ErrorRenderer system by directly adding a custom Serializer normalizer. The Framework already knows how to handle exceptions according to the request format (see SearializerErrorRenderer).

derrabus · 2022-03-07T15:04:09Z

src/Symfony/Component/Serializer/ArgumentResolver/UserInputResolver.php

+        $format = $attribute->format ?? $request->attributes->get('_format', 'json');
+
+        try {
+            $input = $this->serializer->deserialize(data: $request->getContent(), type: $argument->getType(), format: $format, context: $context);


Please use ordered arguments.

jvasseur · 2022-03-07T15:35:06Z

Would it make sense to split this into 2 different features: one that deserialize input and one that validate controller arguments (with 2 separate attributes)?

This would allow to use the deserialize attribute with custom validation logic or the validation one with other argument resolver.

derrabus · 2022-03-07T15:40:51Z

Would it make sense to split this into 2 different features: one that deserialize input and one that validate controller arguments (with 2 separate attributes)?

This would allow us to validate any arguments, not only those that have been deserialized from the request payload. 🤔

GaryPEGEOT · 2022-03-07T15:51:58Z

Would it make sense to split this into 2 different features: one that deserialize input and one that validate controller arguments (with 2 separate attributes)?

This would allow us to validate any arguments, not only those that have been deserialized from the request payload.

Can it be multiple ArgumentResolver for one specific argument ? or does the first ArgumentResolver to supports an argument takes over?

jvasseur · 2022-03-07T15:54:41Z

The first argument resolver take over, the validation would have to be implemented in another way (probably with an event listener).

Co-authored-by: Alexander M. Turek <me@derrabus.de>

GaryPEGEOT · 2022-03-09T17:29:23Z

@lyrixx @dunglas would make sense to create an AbstractProblemNormalizer to regroup ConstraintViolationListNormalizer and the new PartialDenormalizationProblemNormalizer?

…tResolver to split functionalities

lyrixx · 2022-03-10T07:54:59Z

I think yes 👍🏼

BoShurik · 2022-03-15T14:35:41Z

src/Symfony/Component/Serializer/ArgumentResolver/UserInputResolver.php

+        ]);
+        $format = $attribute->format ?? $request->getContentType() ?? 'json';
+
+        yield $this->serializer->deserialize($request->getContent(), $argument->getType(), $format, $context);


It would be great to resolve input not only from request content but from query/request parameters

Something like this:

if ($attribute->isFromQueryString()) { $input = $this->denormalizer->denormalize($request->query->all(), $argument->getType()); } else { if ($request->getContentType() === 'form') { $input = $this->denormalizer->denormalize($request->request->all(), $argument->getType()); } else { $input = $this->serializer->deserialize($request->getContent(), $type, $format); } }

dunglas · 2022-03-18T06:50:38Z

I agree too.

dunglas

To be honest, I would recommend using API Platform instead of adding such code to Symfony.
This is a complex and security sensitive topic (see https://cheatsheetseries.owasp.org/cheatsheets/REST_Security_Cheat_Sheet.html) and by going down the rabbit hole we'll likely end up reimplementing most of API Platform's logic.

dunglas · 2022-03-18T06:53:38Z

src/Symfony/Component/Serializer/ArgumentResolver/UserInputResolver.php

+        $context = array_merge($attribute->context, [
+            DenormalizerInterface::COLLECT_DENORMALIZATION_ERRORS => true,
+        ]);
+        $format = $attribute->format ?? $request->getContentType() ?? 'json';


For security reasons, I suggest to throw an exception if the format isn't provided in the Content-Type header and if the excepted format (the format explicitly passed as parameter by the user) doesn't match the value of Content-Type.

Could we just use $request->toArray()? Or it may be too restrictive in terms of format?

B-Galati · 2022-05-25T20:22:05Z

src/Symfony/Component/Serializer/EventListener/InputValidationFailedExceptionListener.php

+        $response = new Response($this->serializer->serialize($throwable->getViolations(), $format), Response::HTTP_UNPROCESSABLE_ENTITY);
+        $this->logger->info('Invalid input rejected: "{reason}"', ['reason' => (string) $throwable->getViolations()]);
+
+        $event->setResponse($response);


What about stopping propagation as this listener is only here to create the HTTP response?

It's already done: https://github.com/symfony/symfony/blob/6.2/src/Symfony/Component/HttpKernel/Event/RequestEvent.php#L44

B-Galati · 2022-05-25T20:24:02Z

src/Symfony/Component/Serializer/EventListener/InputValidationFailedExceptionListener.php

+    public function __invoke(ExceptionEvent $event): void
+    {
+        $throwable = $event->getThrowable();
+        $format = $event->getRequest()->attributes->get('_format', 'json');


Better use getPreferredFormat that handles the content negotiation part:

Suggested change

$format = $event->getRequest()->attributes->get('_format', 'json');

$format = $event->getPreferredFormat('json');

B-Galati · 2022-05-25T20:25:10Z

src/Symfony/Component/Serializer/ArgumentResolver/UserInputResolver.php

+        $context = array_merge($attribute->context, [
+            DenormalizerInterface::COLLECT_DENORMALIZATION_ERRORS => true,
+        ]);
+        $format = $attribute->format ?? $request->getContentType() ?? 'json';


Could we just use $request->toArray()? Or it may be too restrictive in terms of format?

B-Galati · 2022-05-25T20:26:32Z

src/Symfony/Component/Serializer/ArgumentResolver/UserInputResolver.php

+    {
+        $attribute = $this->getAttribute($argument);
+        $context = array_merge($attribute->context, [
+            DenormalizerInterface::COLLECT_DENORMALIZATION_ERRORS => true,


What about adding AbstractObjectNormalizer::ALLOW_EXTRA_ATTRIBUTES => false?

Nyholm · 2022-07-27T07:11:05Z

To be honest, I would recommend using API Platform instead of adding such code to Symfony.

I've been using this feature for a few months now. I must say that I really love it. It makes is simple to validate API input and have a clear contract with your clients.

I undertand part of API Platform is also solving this issue. But I dont think that would stop us from adding this to Symfony.

lyrixx · 2022-08-01T09:23:52Z

src/Symfony/Component/Serializer/EventListener/InputValidationFailedExceptionListener.php

+        $response = new Response($this->serializer->serialize($throwable->getViolations(), $format), Response::HTTP_UNPROCESSABLE_ENTITY);
+        $this->logger->info('Invalid input rejected: "{reason}"', ['reason' => (string) $throwable->getViolations()]);
+
+        $event->setResponse($response);


It's already done: https://github.com/symfony/symfony/blob/6.2/src/Symfony/Component/HttpKernel/Event/RequestEvent.php#L44

lyrixx · 2022-08-01T09:24:22Z

src/Symfony/Component/Serializer/EventListener/InputValidationFailedExceptionListener.php

+        }
+
+        $response = new Response($this->serializer->serialize($throwable->getViolations(), $format), Response::HTTP_UNPROCESSABLE_ENTITY);
+        $this->logger->info('Invalid input rejected: "{reason}"', ['reason' => (string) $throwable->getViolations()]);


IMHO, the reasons are not really useful in the log

lyrixx · 2022-08-01T09:26:39Z

src/Symfony/Component/Serializer/EventListener/InputValidationFailedExceptionListener.php

+        $throwable = $event->getThrowable();
+        $format = $event->getRequest()->attributes->get('_format', 'json');
+
+        if (!$throwable instanceof InputValidationFailedException) {


Who throw this exception?

faizanakram99 · 2022-11-03T13:11:02Z

Had a similar idea a couple of years ago 😃 #36093 , i am glad we are finally getting an implementation for it (in core)

aszenz · 2022-12-30T17:10:06Z

We use a similar RequestBody attribute to resolve request contents, but recently i found a flaw in it, it doesn't validate that the correct arguments are passed as per php doc block.

<?php
class Preference
{
    public const CATEGORY_1 = 'foo';
    public const CATEGORY_2 = 'bar';

    /**
     * TODO - These types are just for annotation, request body resolver won't validate these when constructing the object from request contents.
     *
     * @param non-empty-string           $option
     * @param self::CATEGORY_* $category
     */
    public function __construct(
        public string $category,
        public string $option,
        public mixed $value = null,
    ) {
    }
}

Does this pr aim to attempt validating against php doc blocks ?

derrabus · 2022-12-30T17:24:59Z

Does this pr aim to attempt validating against php doc blocks ?

I don't think we should do that.

nicolas-grekas · 2023-02-23T17:01:00Z

Shall we close in favor of #49138?

…and `#[MapQueryString]` to map Request input to typed objects (Koc) This PR was merged into the 6.3 branch. Discussion ---------- [HttpKernel] Create Attributes `#[MapRequestPayload]` and `#[MapQueryString]` to map Request input to typed objects | Q | A | ------------- | --- | Branch? | 6.3 | Bug fix? | no | New feature? | yes | Deprecations? | no | Tickets | #36037, #36093, #45628, #47425, #49002, #49134 | License | MIT | Doc PR | TBD Yet another variation of how we can map raw Request data to typed objects with validation. We can even build OpenApi Specification based on this DTO classes using [NelmioApiDocBundle](https://github.com/nelmio/NelmioApiDocBundle). ## Usage Example 🔧 ### `#[MapRequestPayload]` ```php class PostProductReviewPayload { public function __construct( #[Assert\NotBlank] #[Assert\Length(min: 10, max: 500)] public readonly string $comment, #[Assert\GreaterThanOrEqual(1)] #[Assert\LessThanOrEqual(5)] public readonly int $rating, ) { } } class PostJsonApiController { public function __invoke( #[MapRequestPayload] PostProductReviewPayload $payload, ): Response { // $payload is validated and fully typed representation of the request body $request->getContent() // or $request->request->all() } } ``` ### `#[MapQueryString]` ```php class GetOrdersQuery { public function __construct( #[Assert\Valid] public readonly ?GetOrdersFilter $filter, #[Assert\LessThanOrEqual(500)] public readonly int $limit = 25, #[Assert\LessThanOrEqual(10_000)] public readonly int $offset = 0, ) { } } class GetOrdersFilter { public function __construct( #[Assert\Choice(['placed', 'shipped', 'delivered'])] public readonly ?string $status, public readonly ?float $total, ) { } } class GetApiController { public function __invoke( #[MapQueryString] GetOrdersQuery $query, ): Response { // $query is validated and fully typed representation of the query string $request->query->all() } } ``` ### Exception handling 💥 - Validation errors will result in an HTTP 422 response, accompanied by a serialized `ConstraintViolationList`. - Malformed data will be responded to with an HTTP 400 error. - Unsupported deserialization formats will be responded to with an HTTP 415 error. ## Comparison to another implementations 📑 Differences to #49002: - separate Attributes for explicit definition of the used source - no need to define which class use to map because Attributes already associated with typed argument - used ArgumentValueResolver mechanism instead of Subscribers - functional tests Differences to #49134: - it is possible to map whole query string to object, not per parameter - there is validation of the mapped object - supports both `$request->getContent()` and `$request->request->all()` mapping - functional tests Differences to #45628: - separate Attributes for explicit definition of the used source - supports `$request->request->all()` and `$request->query->all()` mapping - Exception handling opt-in - functional tests ## Bonus part 🎁 - Extracted `UnsupportedFormatException` which thrown when there is no decoder for a given format Commits ------- d987093 [HttpKernel] Create Attributes `#[MapRequestPayload]` and `#[MapQueryString]` to map Request input to typed objects

carsonbot added Status: Needs Review Feature FrameworkBundle labels Mar 3, 2022

carsonbot added this to the 6.1 milestone Mar 3, 2022

Nyholm reviewed Mar 3, 2022

View reviewed changes

derrabus added the Serializer label Mar 3, 2022

carsonbot changed the title ~~[FrameworkBundle] Add an ArgumentResolver to deserialize & validate user input~~ [FrameworkBundle][Serializer] Add an ArgumentResolver to deserialize & validate user input Mar 3, 2022

derrabus requested changes Mar 3, 2022

View reviewed changes

carsonbot added Status: Needs Work and removed Status: Needs Review labels Mar 3, 2022

lyrixx reviewed Mar 4, 2022

View reviewed changes

GaryPEGEOT requested a review from dunglas as a code owner March 5, 2022 09:27

carsonbot added Status: Needs Review and removed Status: Needs Work labels Mar 5, 2022

GaryPEGEOT commented Mar 5, 2022

View reviewed changes

derrabus reviewed Mar 6, 2022

View reviewed changes

mbabker mentioned this pull request Mar 6, 2022

[Meta] Impact of SensioFrameworkExtraBundle deprecation FriendsOfSymfony/FOSRestBundle#2354

Open

GaryPEGEOT force-pushed the feat/user-input-resolver branch from 19f395a to a5caa1b Compare March 6, 2022 17:24

yceruto requested changes Mar 7, 2022

View reviewed changes

carsonbot added Status: Needs Work and removed Status: Needs Review labels Mar 7, 2022

derrabus reviewed Mar 7, 2022

View reviewed changes

GaryPEGEOT and others added 6 commits March 9, 2022 17:30

Apply suggestion

2368c7f

Co-authored-by: Alexander M. Turek <me@derrabus.de>

fix: remove getters

5905ae0

feat: make validation optional

406f1eb

fix: cs

7f7500c

fix: tests

eae458f

fix: content-type guessing

1523617

refactor: rename Input to RequestBody, remove validator from UserInpu…

5976a4b

…tResolver to split functionalities

GaryPEGEOT force-pushed the feat/user-input-resolver branch from 9e90c03 to 5976a4b Compare March 9, 2022 17:32

fix: remove useless argument

ebeee98

BoShurik reviewed Mar 15, 2022

View reviewed changes

dunglas requested changes Mar 18, 2022

View reviewed changes

fabpot modified the milestones: 6.1, 6.2 May 20, 2022

derrabus mentioned this pull request May 25, 2022

[RFC] Add request specific annotations #36037

Closed

B-Galati reviewed May 25, 2022

View reviewed changes

derrabus mentioned this pull request May 31, 2022

[DoctrineBridge] Add an Entity Argument Resolver #43854

Merged

lyrixx reviewed Aug 1, 2022

View reviewed changes

nicolas-grekas modified the milestones: 6.2, 6.3 Nov 5, 2022

faizanakram99 mentioned this pull request Jan 30, 2023

[HttpKernel] Create Attributes #[MapRequestPayload] and #[MapQueryString] to map Request input to typed objects #49138

Merged

GaryPEGEOT closed this Feb 23, 2023


		$errors = new ConstraintViolationList();

		foreach ($e->getErrors() as $exception) {

	$format = $event->getRequest()->attributes->get('_format', 'json');
	$format = $event->getPreferredFormat('json');

Uh oh!

[FrameworkBundle][Serializer] Add an ArgumentResolver to deserialize & validate user input #45628

[FrameworkBundle][Serializer] Add an ArgumentResolver to deserialize & validate user input #45628

Uh oh!

Conversation

GaryPEGEOT commented Mar 3, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Nyholm left a comment

Choose a reason for hiding this comment

Uh oh!

Uh oh!

Uh oh!

Uh oh!

mathsunn commented Mar 3, 2022

Uh oh!

derrabus commented Mar 3, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

lyrixx left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

GaryPEGEOT commented Mar 5, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

derrabus commented Mar 6, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Uh oh!

yceruto left a comment

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

derrabus Mar 7, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yceruto Mar 7, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yceruto Mar 7, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

Choose a reason for hiding this comment

Uh oh!

yceruto Mar 7, 2022 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

GaryPEGEOT commented Mar 3, 2022 •

edited

Loading

derrabus commented Mar 3, 2022 •

edited

Loading

GaryPEGEOT commented Mar 5, 2022 •

edited

Loading

derrabus commented Mar 6, 2022 •

edited

Loading

derrabus Mar 7, 2022 •

edited

Loading

yceruto Mar 7, 2022 •

edited

Loading

yceruto Mar 7, 2022 •

edited

Loading

yceruto Mar 7, 2022 •

edited

Loading