fix(api): seperate and fix user add and update endpoint logic

[LuukBlankenstijn]

Found some bugs while using the API, and since I need the endpoints, fixed them.

Problem I encountered:
Endpoint /api/v4/users/{id} PUT request returned{ 400, Body data exceeded php.ini's 'post_max_size' directive (currently set to 512M)}.
Could not get it to work whatever I tried. When looking at the code I also discovered some other issues in the case of updating the user with App\Controller\API\UserController.php addOrUpdateUser().
What I did is changing the content type of the api-doc attribute to application/json, and separated the add and update method in to dedicated methods. I realize this is a breaking change in the api spec and not ideal.

I got the errors on both the DOMjudge instance running on the GEHACK server in Eindhoven, and my own local instance.

This exception is generated in App\EventListener\BodyToBigListener.php. This happens because the amount of parameters on the request is 0. (I get this even when using /api/doc on a running domjudge instance). I first tried fixing the request, but could not get it to work. Because it made more sense to me for a request like this to accept json instead of formdata I decided to change it to that. After I did this the request now worked, but i found some flaws in the update logic for user.

For example: name, username and id are required to even make an update by the documentation. I would have expected to just need an id and being able to update any field. Then, on line 150 in App\Controller\Api\Usercontroler:

protected function addOrUpdateUser(AddUser $addUser, Request $request): Response
    {
        if ($addUser instanceof UpdateUser && !$addUser->id) {
            throw new BadRequestHttpException('`id` field is required');
        }

        if ($this->em->getRepository(User::class)->findOneBy(['username' => $addUser->username])) {
            throw new BadRequestHttpException(sprintf("User %s already exists", $addUser->username));
        }
        $user = new User();
              if ($addUser instanceof UpdateUser) {
                  $existingUser = $this->em->getRepository(User::class)->findOneBy(['externalid' => $addUser->id]);
                  if ($existingUser) {
                      $user = $existingUser;
                  }
              }

        $user
            ->setUsername($addUser->username)
            ->setName($addUser->name)
            ->setEmail($addUser->email)
            ->setIpAddress($addUser->ip)
            ->setPlainPassword($addUser->password)
            ->setEnabled($addUser->enabled ?? true);

       // rest of method
}

So if the user already exists we get a BadRequestException. This effectively means that for every update we want to do to a user, the username has to be changed.
Then also we cannot do partial update by leaving fields in the request null, since all properties of the UpdateUser dto are assigned to the existing user, even when null.

[vmcj]

Can you explain which problem you encountered?

[LuukBlankenstijn]

Updated the description

[vmcj]

Found some bugs while using the API, and since I need the endpoints, fixed them.

Problem I encountered: Endpoint /api/v4/users/{id} PUT request returned{ 400, Body data exceeded php.ini's 'post_max_size' directive (currently set to 512M)}.

Let's discuss in Slack how to fix this one, I assume you posted something which is larger than 512M? Did you raise the post_max_size? You can check for the value detected in the config checker.

... When looking at the code I also discovered some other issues in the case of updating the user with App\Controller\API\UserController.php addOrUpdateUser(). What I did is changing the content type of the api-doc attribute to application/json,

I can see that you did this, but I'm not sure yet why it wants a form but I suspect this is legacy.

and separated the add and update method in to dedicated methods. I realize this is a breaking change in the api spec and not ideal.

So we're working on a major release so now would be the time to make such choices but let's see if we can prevent it still.

[vmcj]

I think it's fine to also allow PUT here, but dropping POST doesn't make sense to me.

[vmcj]

PHPstan does not agree with removing this.

[LuukBlankenstijn]

Yeah sorry, I forgot to run PHPstan

[vmcj]

@LuukBlankenstijn can you provide the files you were using which hit this error?

[eldering]

I've not looked into the changes in detail (and I guess @nickygerritsen might be a better reviewer), but from the description it's not clear to me what these changes are fixing and why/how. Because this seems to have nothing to do with a maximum post size of a request. Can you clarify that?

[LuukBlankenstijn]

I updated the description again, I'm sorry for lack initial lack of explanation

[nickygerritsen]

I think we can do something smart to still have both update and create in one action, will think about it.

Although that is not very REST, so maybe we shouldn't?

As form json vs formdata, ideally it'd accept both, so I will investigate if we can get that to work.