-
-
Notifications
You must be signed in to change notification settings - Fork 317
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
Apply naming convention for Rights, Capabilites etc. #1511
Conversation
7d3359a
to
b205fbb
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.
I appreciate the endeavor. However, this PR still mixes capabilities and rights. If we go for it (we should), we should try to get it correct this time.
And back to the drawing boards. 😆 |
23278b2
to
191afa8
Compare
This PR is getting "a bit" bigger than I expected. Sorry @nagmat84 |
I am not sure yet if this is 100% merge ready. I tried to cover quite a few of the corner cases. Nevertheless, as always I expect a lots of complaints of @nagmat84 so here we go for a first round of reviews. :D |
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.
Reviewed 22 of 91 files.
@@ -64,7 +64,7 @@ public function get(): TopAlbums | |||
$smartAlbums = $this->albumFactory | |||
->getAllBuiltInSmartAlbums(false) | |||
->map( | |||
fn ($smartAlbum) => Gate::check(AlbumPolicy::IS_VISIBLE, $smartAlbum) ? $smartAlbum : null | |||
fn ($smartAlbum) => Gate::check(AlbumPolicy::CAN_SEE, $smartAlbum) ? $smartAlbum : null |
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 need to think some time, if I like this or should hate it.
This is perfectly fine with respect to the systematics to start the name of a right with CAN...
. CAN_VISIBLE
obviously makes no sense and CAN_SEE
is in perfect line with CAN_DOWNLOAD
, CAN_ACCESS
, CAN_ARCHIVE
, ..., etc. So actually I should like it.
But we also have a "visibility filter" in the query policy which is strongly related to this right and hence the verb should not change. :(
$user->may_edit_own_settings = true; | ||
$user->may_administrate = 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.
Given this two lines, I need to share a (fun) story which happened to me recently during a discussion with a CC evaluator.
In CC language "administration" (or "administrate") is nothing technical, but conducted by the operating organization. For example, the HR department administrates matters related to employees and employments. "Configuration" (or "configure") is something which happens during manufacturing or procurement. For example, a firewall may have different form factors (19" rack mountable with 48 ports, table-top small form factor with 8 ports, etc.) but still be the same product from evaluation perspective with different configurations. However, settings which are changed by a privilege user role at runtime are managed.
We also used the terms in different meanings and the evaluator was completely derailed. He was completely puzzled how a user should be able to configure settings at runtime. (We used "configure settings" instead of "manage settings"). In the end we had to change our wording. Luckily we do not plan to get a CC evaluation for Lychee, otherwise it should probably be may_self_manage
and may_manage
.
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.
57 of 91 files.
@@ -26,7 +26,7 @@ class ChangeLoginRequest extends BaseApiRequest implements HasPassword | |||
*/ | |||
public function authorize(): bool | |||
{ | |||
return Gate::check(UserPolicy::CAN_EDIT_SETTINGS, User::class); | |||
return Gate::check(UserPolicy::CAN_EDIT_OWN_SETTINGS, User::class); |
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.
In order to follow the general systematics we need something like this
return Gate::check(UserPolicy::CAN_EDIT_SETTINGS, [User::class, Auth::user()]);
This might look a little bit weird on the first glance, but makes a lot of sense if one keeps in mind that the currently authenticated user has rights on some object (and this object happens to be the user itself). The UserPolicy
has to look like this
class UserPolicy {
public function canEditSettings(User $user, User $otherUser): void
{
// Bypass for administrators is granted by `before`, so we only need to deal with the case of self-editing here
return $user->id === $otherUser->id;
}
}
@@ -15,7 +15,7 @@ class SetEmailRequest extends BaseApiRequest | |||
|
|||
public function authorize(): bool | |||
{ | |||
return Gate::check(UserPolicy::CAN_EDIT_SETTINGS, User::class); | |||
return Gate::check(UserPolicy::CAN_EDIT_OWN_SETTINGS, User::class); |
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.
See some comments above. In order to stay systematic we should use
return Gate::check(UserPolicy::CAN_EDIT_SETTINGS, [User::class, Auth::user()]);
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.
74 of 91 files. That is everything except for the tests.
|
||
// rename the column | ||
Schema::table('users', function (Blueprint $table) { | ||
$table->renameColumn('is_locked', 'may_edit_own_settings'); |
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 need to check whether renaming a columns breaks foreign constraints for SQLite. I have that feeling that renaming was mimicked by deleting and re-creating the table and forgetting foreign key constraints on that way.
database/migrations/2022_09_12_175257_rename_attributes_grants.php
Outdated
Show resolved
Hide resolved
database/migrations/2022_09_12_175257_rename_attributes_grants.php
Outdated
Show resolved
Hide resolved
database/migrations/2022_09_12_175257_rename_attributes_grants.php
Outdated
Show resolved
Hide resolved
database/migrations/2022_09_12_175257_rename_attributes_grants.php
Outdated
Show resolved
Hide resolved
f2dce40
to
16c9949
Compare
Rebased on top of #1529 |
@nagmat84 I would suggest you have another look. There should not be many changes left to be done hopefully. |
@nagmat84 I tried to cover all your comments. :) So far, the only part missing is on @kamil4 @qwerty287 @d7415 Enjoy the review. :) |
Considering closing this, squash and open a new PR in order to have a clean history and remove resolved comments. :') |
I don't mind either way. But in case you decide to "restart", I would not review this PR but wait until you have decided. |
I'll do that then. |
This PR builds on #1508 so merging this one will automatically merge the previous one.
Content:
Drops the Admin Middleware
move authorization to Gates on Requests
Increase number of Policy & granularity of Rights
creates DTO for:
renames capabilities with regard to [Enhancement] Giving security attributes better names #1481
drops visibility for sharing links per album in favor of the already existing global setting.
adds stricter tests on Locale and remove extra keys in other languages than English
TODO (maybe future PR?) :