-
Notifications
You must be signed in to change notification settings - Fork 4.8k
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
Migrate login and authentication in Back Office to Symfony #35983
Conversation
Hi, thanks for this contribution! I found some issues with the Pull Request description:
Would you mind having a look at it? This will help us understand how interesting your contribution is, thank you very much! About linked issuesPlease consider opening an issue before submitting a Pull Request:
(Note: this is an automated message, but answering it will reach a real human) |
5d4b466
to
46ff748
Compare
9adc35e
to
0665025
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.
Does not seem to reimplement PS_COOKIE_CHECKIP removed. This feature allows to enable/disable checking IP address of the session.
Correct me and remove the block if I am wrong. :-)
src/PrestaShopBundle/Security/Admin/AdminAuthenticationSuccessHandler.php
Show resolved
Hide resolved
I didn't know about this one, just like the cron URLs feature I added this in the epic #36001 The present PR is already big enough but it still passes all our autotests, a few left tasks are already identified and will be handled in smaller PRs, if you have other thoughts about missing things feel free to let us know so that we can add them into the epic I don't think we should block the PR though considering it already handles maybe 90% of the whole login/authorization feature and I can guarantee that all the remaining tasks will be dealt with right after this PR is merged 😉 |
$response = $kernel->handle($request, HttpKernelInterface::MAIN_REQUEST, true); | ||
$response->send(); | ||
$kernel->terminate($request, $response); |
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.
Finally 👍
@jolelievre No worries, I trust you. Let's merge this so the PR doesn't keep growing. I added the notes to #36001. ;-) |
prestashop.adapter.security.admin: | ||
class: "%AdapterSecurityAdminClass%" | ||
arguments: | ||
- "@prestashop.adapter.legacy.context" | ||
- "@security.token_storage" | ||
- "@prestashop.security.admin.provider" | ||
- "@security.helper" | ||
tags: | ||
- { name: kernel.event_listener, event: kernel.request, method: onKernelRequest } | ||
|
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.
👏
autowire: true | ||
autoconfigure: true |
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.
Not necessary due to default value
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 note to remove it in the next PR 😉
cookie_key: ThisTokenIsNotSoSecretChangeIt | ||
cookie_iv: ThisTokenIsNotSoSecretChangeIt |
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.
We could put this in environment variables
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.
Yep for now they are default parameters, if we use env variables we can always use the env
directive in the parameters, but currently we transform parameters in a PHP file so we can't really enjoy this feature To use this we should do a small refacto to actually use the parameters.yml
file
I believe I had to add those default values here because they would make the SF console break when absent at some point, and it's more consistent to have all the required fields in the dist file anyway
/** | ||
* @ORM\Column(name="email", type="string") | ||
*/ | ||
private string $email; |
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.
Is it interesting to add a unique constraint to this field?
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.
Not for now, the Doctrine entity is not used in edition (not in the form nor in the CQRS commands), so they would be useless The should be added when we refacto the CQRS commands I guess
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.
Argh my bad I misunderstood I thought you were talking about assertions for the entity validation Regarding the unicity of this column you're completely right But it's a change of the DB structure I prefer to handle it in another PR, we also discussed in another comment about removing the theme customizations field, I guess all this could be handled in a dedicated PR
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.
Ok 👍
|
||
/** | ||
* @ORM\Column(name="bo_color", type="string", length=32, nullable=true) | ||
*/ | ||
private ?string $boColor; | ||
|
||
/** | ||
* @ORM\Column(name="bo_theme", type="string", length=32, nullable=true) | ||
*/ | ||
private ?string $boTheme; | ||
|
||
/** | ||
* @ORM\Column(name="bo_css", type="string", length=64, nullable=true) | ||
*/ | ||
private ?string $boCss; | ||
|
||
/** | ||
* @ORM\Column(name="bo_width", type="integer", options={"default": 0, "unsigned": true}) | ||
*/ | ||
private int $boWidth; | ||
|
||
/** | ||
* @ORM\Column(name="bo_menu", type="boolean", options={"default": 1}) | ||
*/ | ||
private bool $boMenu; |
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.
When I see that I tell myself that it could go to another entity
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 is no longer used, maybe we can use this opportunity to remove this 💩?
bo_color
bo_width
bo_theme (there is only default)
bo_menu
Ping @kpodemski correct me if I miss something
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 don't mind, for now I had to leave them in the Doctrine entity or the doctrine command would automatically delete these fields, so I had to sync the content of the entity with the db structure table
We could clean those, but in another PR then
Hello @jolelievre, I tested your PR and it's good for me! 🎉 Thanks! |
Hello @jolelievre |
Related Autoupgrade PR - PrestaShop/autoupgrade#954 |
Manual checks:
- check login to BO
- check logout from BO
- check password reset feature
- check permission are consistent with assigned profile
- check profile edition