-
Notifications
You must be signed in to change notification settings - Fork 899
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
Add my_settings_view product feature for the My Settings page #22779
Conversation
bcc32bd
to
4f50270
Compare
- :name: View | ||
:description: View My Settings | ||
:feature_type: view | ||
:identifier: my_settings_view |
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.
Note to self - we might want a database migration adding this to any existing role that has one of the other my_settings permissions.
# a super admin by virtue of being in multiple groups, then they will be filtered by | ||
# with_roles_excluding. The allowed_ids option ensures the user can still see themselves. | ||
# | ||
# TODO: Determine if this same logic should apply to MiqUserRole as well |
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.
So we would want role here to prevent a tenant admin from creating a group with super admin privs? i.e.: "everything"
?
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'm not really sure here. I need to allow the user themselves when it gets filtered out, but if a currently-non-admin user can be a super-admin, does that mean they should or shouldn't be able to see the super admin role? I'm just not sure.
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.
the goal here is to prevent a tenant admin from creating a super user. (that they then know the password so they can escalate privileges.
You can do that via using a super group, or creating a group and assigning a super role
# In the case that the user is not currently in a super admin group, but can _become_ | ||
# a super admin by virtue of being in multiple groups, then they will be filtered by | ||
# with_roles_excluding. The allowed_ids option ensures the user can still see themselves. |
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.
yea, this edge case is only for when an admin changes to another group to determine what that other group can see. (to view what one of their users can see)
Such an edge case, but an important one to help admins understand the security implications
spec/lib/rbac/filterer_spec.rb
Outdated
end | ||
|
||
context "with self-service user" do | ||
context "where the user is in another group that is a regular group" do |
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 really like using with for contexts.
context "where the user is in another group that is a regular group" do | |
context "with a regular group" do |
But maybe where is better since the subject is the rbac and not the user
context "where the user is in another group that is a regular group" do | |
context "with the user also in a regular group" do |
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.
Yeah I was debating the wording - I like the latter there.
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.
Yea,
I think you want to create shared_group
in the case where a group is shared by other_user.
But I think you want other_group
to be present in all cases where the main user is not in other_group
.
That is the sad path.
That way we truly understand how the user views other groups. (groups in this tenant, but not a member)
unsure about this idea:
Don't have other_user.miq_groups << my_group
, but use shared_group
instead?
other_user.miq_groups << group | ||
get_rbac_results_for_and_expect_objects(User, [user, other_user]) | ||
end | ||
context "with other users in the group" do |
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 think the fact that other users are in the group is a given/base case and should not be a context. (starts to make it indention happy)
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.
yeah I was struggling here - it's important to have multiple users to show which ones are or aren't coming back. These tests are bigger than the "self" case.
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 decided to keep it. Reason it that otherwise you just have these floating it
s and it's hard to tell why they aren't in a context and what makes them special.
spec/lib/rbac/filterer_spec.rb
Outdated
end | ||
|
||
it "returns only the current user" do | ||
get_rbac_results_for_and_expect_objects(User, [user]) | ||
context "and the current_group is the original regular group" do |
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.
context "and the current_group is the original regular group" do | |
context "and the current_group is a regular group" do |
unsure the difference between this context and the next context.
Is it simply that there are or are not other users in the group?
Maybe just create a user in the group and not in the group and you'll handle the happy and sad paths?
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.
aah. If you use shared_group, I think the language will end up better. (so you could use shared group for a context where the group is shared)
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.
Yeah i used shared group
end | ||
|
||
let!(:user_role) do | ||
FactoryBot.create(:miq_user_role, :role => "user") | ||
it "returns only the current user" do |
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 this avoiding returning other users in this group?
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.
Yes, self_service is defined to only return yourself even if other users are present, whereas a non-self_service group is defined to returns all users in the groups.
end | ||
end | ||
|
||
context "with a self_service user" do |
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 a regular self service user and not a limited self service user. right?
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.
That's correct
end | ||
|
||
context "that is in multiple groups" do |
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.
do we need separate tests for a single group vs multiple groups?
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.
Probably not, but I was struggling here. It felt important to me to have a bunch of tests dedicated to multiple groups, so that future changes could take them into account specifically.
spec/lib/rbac/filterer_spec.rb
Outdated
end | ||
|
||
it "returns user's groups" do | ||
get_rbac_results_for_and_expect_objects(MiqGroup, [other_group]) # TODO: should this be [group, other_group] ??? |
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.
no. I think this is right.
Per the other examples, other_group
is the only active/current group
(yes, I wish current_group were not a concept and both were returned, but that is not the current concept)
spec/lib/rbac/filterer_spec.rb
Outdated
allow_any_instance_of(MiqGroup).to receive_messages(:self_service? => true) | ||
other_user # ensure we create another user in the other group | ||
|
||
user.miq_groups << other_group |
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.
if you want both users to be in the same group, please create a new group and put both users into it shared_group
?
4f50270
to
a8863e6
Compare
a8863e6
to
238282a
Compare
238282a
to
aa96c28
Compare
Checked commits Fryguy/manageiq@f8b19be~...aa96c28 with ruby 2.6.10, rubocop 1.28.2, haml-lint 0.35.0, and yamllint lib/rbac/filterer.rb
|
let!(:super_administrator_user_role) do | ||
FactoryBot.create(:miq_user_role, :role => "super_administrator") | ||
before do | ||
other_user # ensure we create another user in another group |
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.
thank you for including the unhappy path. this gives me a lot of confidence
Backported to
|
Add my_settings_view product feature for the My Settings page (cherry picked from commit 6ebac25)
Additionally fixes an RBAC issue where users can sometimes not see themselves.
Depended on by