-
Notifications
You must be signed in to change notification settings - Fork 3
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
IBX-8290: Reworked REST authentication to comply with the new Symfony authenticator mechanism under separate firewall #98
Conversation
36ff001
to
9939569
Compare
9cd39ca
to
83ce0fc
Compare
946ea79
to
363f36d
Compare
1e30962
to
292d7dc
Compare
After internal sync, I improved |
283bef7
to
9c8f8c2
Compare
9c8f8c2
to
b23cde0
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This overall looks very solid. Great work 💪
I have some insignificant/cosmetic remarks:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I didn't find any major technical issues. The direction is in line with what we've discussed on the meetings. I only have some minor nitpicks and I spotted a few places where more PHP 8.3 features could be enforced (constructor promotion, readonly etc.).
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Errors in tests that occurred can be narrowed down to these issues:
UDW displays incomplete tree.
(Missing items: Users, Site skeletons, Corporate Account i Dashboards)
This can be reproduced in various places. E.g. when assigning items to Roles or Sections. When trying to Move items. When setting up File field in Form Builder etc.
New field types cannot be added (e.g. ezcountry, ezdate, eztext).
This can be reproduced when creating new Content Type or Product Type. Error occurs when new field type is dragged into the Field definitions section ("Not Found" error in UI).
Add to bookmarks doesn't work.
This can be reproduced by adding item to bookmarks and reloading the page (item is not marked as bookmarked)
Multi file upload doesn't work.
Either when using drag and drop or the "Upload file" button. File is being uploaded, progress bar is shown but error occurs at the end.
Several locations cannot be loaded in admin panel using the left side menu. UI shows error "Cannot read properties of undefined (reading 'subitems')".
Affects: Users, Corporate, Dashboards, Site skeletons.
Reported issue should be resolved via ibexa/recipes-dev@a7190fb. Explanation: ibexa/recipes-dev#121 (comment). I will restart the CI here just to be sure nothing got broken, early testing looks promising. |
Quality Gate passedIssues Measures |
Related PRs:
Description:
This PR is about reworking REST API authorization to comply with the new Symfony authenticator mechanism. Below I describe my reasoning and technical details under the hood.
1. How was it done till today?
Lots of code around REST authorization orbits around concept that REST API requests are handled by the same
ibexa_front
firewall which is used for the regular authorization within Ibexa DXP. This doesn't seem to be necessary so basic idea is to move it to a dedicated firewall - ref: ibexa/recipes-dev#121.2. What is the idea?
My main focus was to:
a) keep existing authorization calls (
POST /user/sessions
) in-tact,b) switch to a separate firewall
c) use built-in authenticator (tried with
json_login
ref: https://symfony.com/doc/5.x/security.html#json-login) but it proved to not work correctly and limited us to use JSON-based credentials only.Keeping all that in mind I decided to implement a custom authenticator (
Ibexa\Rest\Security\Authenticator\RestAuthenticator
) which from now on will be referenced in our security configuration. It tries to mimic the behavior coming from the oldsrc/lib/Server/Security/RestAuthenticator.php
but with some caveats.3. Why removing the old authenticator?
There are handful of reasons:
Ibexa\Core\MVC\Symfony\Security\Authentication\AuthenticatorInterface
which doesn't seem to be needed at all given we switch to the Symfony way of performing authorization,InteractiveLoginEvent
which doesn't seem to be needed - our custom authenticator implementsSymfony\Component\Security\Http\Authenticator\InteractiveAuthenticatorInterface
which does that under the hood, ref: https://symfony.com/doc/5.x/security.html#other-events,logout
operation which is based on already deprecatedSymfony\Component\Security\Http\Logout\SessionLogoutHandler
- the new authenticator handles that properly.4. How to hook into the new authorization system?
My idea is to have it triggered automatically only on requests to POST /user/sessions endpoint, like it was done before. It's implemented via
public function supports(Request $request): ?bool
to be invoked whenever proper_route
attribute is present (ibexa.rest.create.session
).Since it's out own implementation, we have a full control over how it's triggered ergo we can change it to be more robust or put some extension point in place.
Other important changes:
ibexa_rest_session: ~
firewall config key alongsidesrc/bundle/DependencyInjection/Security/RestSessionBasedFactory.php
since (to the best of my knowledge) its main purpose was to customize form login and allow REST authorization to reside on the same firewall as the regular authorization,src/bundle/EventListener/CsrfListener.php
,Ibexa\Rest\Server\Security\RestLogoutHandler
based on the deprecated Symfony mechanism,class_alias
entries inside the classes affected by this PR,tests/bundle/EventListener/EventListenerTest.php
and its derivatives,Open questions:
shouldreworked to be triggered only onRestAuthenticator
be triggered under some other conditions rather than by analyzing request headers?ibexa.rest.create_session
matched route,whenever wrong credentials are sent, the response code is nowwe should (after team sync)500
with some generic Symfony message - should we adjust it to the previous401
instead?For QA:
Sanities on all the REST API endpoints might become necessary, especially on those around authorization except JWT - it will be re-implemented in the next steps.
Documentation: