Two configuration options need to be enabled to allow user registration via the API:
1) fosuser_registration, which indicates whether registration is allowed at all (frontend and API)
2) api_user_registration, which indicates whether registration is allowed via the API
This PR is based on 2.5.x branch.
We fix the improper authorization by retrieving the annotation using id
and user id.
We also replace the ParamConverter used to get the requested Annotation
on put and delete actions with an explicit call to AnnotationRepository
in order to prevent a resource enumeration through response discrepancy.
Fixes GHSA-mrqx-mjc4-vfh3
Co-authored-by: Jeremy Benoist <jeremy.benoist@gmail.com>
Signed-off-by: Kevin Decherf <kevin@kdecherf.com>
Most of the API annotations are directly converted. The changes in meaning are:
- Parameters "in body" is not supported anymore. These are changed to "in query" or to a request body (depending on the code).
Mostly using autowiring to inject deps.
The only tricky part was for import because all producer use the same class and have a different alias. So we must write them down in the service definition, autowiring doesn't work in that case.
Usually:
- if a controller has a constructor, it means injected services are at least re-used once in actions
- otherwise, service are injected per action
Looks like parameter for the `->dispatch(` have been flipped (event first then event name).
Define events should now extends `Symfony\Contracts\EventDispatcher\Event`
- disable autowiring for Event (because the Entry entity was injected)
- rename `getClient()` for test to `getTestClient()` to avoid error while overriding (from `BrowserKitAssertionsTrait`)
As baggy theme was removed and material is the only remaining theme, we don't need a theme switched anymore.
So:
- move all `*.twig` files from the material theme folder to the root
- remove useless translations
I've noticed that the endpoint `/api/entries/exists` used by the "Sweep
articles" feature on the Android app failed almost all the time on my
instance.
After checking the corresponding method I found that
`EntryRestController::getEntriesExistsAction()` could be improved.
Here is the former way the method worked:
```
for id in [list of ids]
get full entry by id
if null
get full entry by given id
return array of ids or array of hashes
```
With this behavior on my instance I could expect up to 13k SQL requests
when sweeping articles from the Android app. Morever the repository
fetches all fields (content included) while the method only returns ids
or hashes.
The new behavior is described as follow:
```
get ids, hashes by [list of ids]
merge with provided [list of ids] // this part will complete the final
// array with not found ids
return array of ids or array of hashes
```
In my case this change reduces the number of SQL requests to only 135
(_considering one request for 50 articles_)
Signed-off-by: Kevin Decherf <kevin@kdecherf.com>
