Skip to content
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

Merged
merged 2 commits into from
Nov 14, 2023

Conversation

Fryguy
Copy link
Member

@Fryguy Fryguy commented Nov 7, 2023

@Fryguy Fryguy changed the title Add my_settings_view product feature for the My Settings page [WIP] Add my_settings_view product feature for the My Settings page Nov 7, 2023
@Fryguy Fryguy added the bug label Nov 7, 2023
@miq-bot miq-bot added the wip label Nov 7, 2023
- :name: View
:description: View My Settings
:feature_type: view
:identifier: my_settings_view
Copy link
Member Author

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.

lib/rbac/filterer.rb Outdated Show resolved Hide resolved
# 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
Copy link
Member

@kbrock kbrock Nov 8, 2023

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"?

Copy link
Member Author

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.

Copy link
Member

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

Comment on lines +639 to +642
# 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.
Copy link
Member

@kbrock kbrock Nov 8, 2023

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

end

context "with self-service user" do
context "where the user is in another group that is a regular group" do
Copy link
Member

@kbrock kbrock Nov 8, 2023

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.

Suggested change
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

Suggested change
context "where the user is in another group that is a regular group" do
context "with the user also in a regular group" do

Copy link
Member Author

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.

Copy link
Member

@kbrock kbrock left a 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?

spec/lib/rbac/filterer_spec.rb Outdated Show resolved Hide resolved
spec/lib/rbac/filterer_spec.rb Outdated Show resolved Hide resolved
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
Copy link
Member

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)

Copy link
Member Author

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.

Copy link
Member Author

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 its and it's hard to tell why they aren't in a context and what makes them special.

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
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Suggested change
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?

Copy link
Member

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)

Copy link
Member Author

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
Copy link
Member

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?

Copy link
Member Author

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
Copy link
Member

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?

Copy link
Member Author

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
Copy link
Member

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?

Copy link
Member Author

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.

end

it "returns user's groups" do
get_rbac_results_for_and_expect_objects(MiqGroup, [other_group]) # TODO: should this be [group, other_group] ???
Copy link
Member

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)

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
Copy link
Member

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?

@Fryguy Fryguy changed the title [WIP] Add my_settings_view product feature for the My Settings page Add my_settings_view product feature for the My Settings page Nov 14, 2023
@miq-bot miq-bot removed the wip label Nov 14, 2023
@miq-bot
Copy link
Member

miq-bot commented Nov 14, 2023

Checked commits Fryguy/manageiq@f8b19be~...aa96c28 with ruby 2.6.10, rubocop 1.28.2, haml-lint 0.35.0, and yamllint
6 files checked, 1 offense detected

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
Copy link
Member

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

@kbrock kbrock merged commit 6ebac25 into ManageIQ:master Nov 14, 2023
6 checks passed
@Fryguy
Copy link
Member Author

Fryguy commented Nov 14, 2023

Backported to quinteros in commit cb2ab3b.

commit cb2ab3b31626fc372a8e3a9eb9494c9372013d79
Author: Keenan Brock <keenan@thebrocks.net>
Date:   Tue Nov 14 17:49:15 2023 -0500

    Merge pull request #22779 from Fryguy/fix_my_settings
    
    Add my_settings_view product feature for the My Settings page
    
    (cherry picked from commit 6ebac25d22a501a1522834a23a111ed5a101d407)

Fryguy pushed a commit that referenced this pull request Nov 14, 2023
Add my_settings_view product feature for the My Settings page

(cherry picked from commit 6ebac25)
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants