-
Notifications
You must be signed in to change notification settings - Fork 3k
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
[HOLD for payment 2023-07-26] [$1000] Web - UserB can access the room "Welcome message" page and update it without permission #22013
Comments
ProposalPlease re-state the problemUnauthorized users are able to edit the welcome message of the workspace room. What is the root cause of that problem?The root cause is that there are no checks in place either on the backend or the front-end if the user has access to the workspace as an admin. What changes do you think we should make to solve this problem?On the front-end, we should prevent the user from accessing the First we need to add the withOnyx({
policy: {
key: ({report}) => `${ONYXKEYS.COLLECTION.POLICY}${report.policyID}`
}
}), Here are the possible approaches:
Option 1 useEffect(() => {
if (PolicyUtils.isPolicyAdmin(props.policy)) {
return;
}
Navigation.goBack();
}, [props.policy]); Option 2 const shouldHide = _.isEmpty(props.report) || !PolicyUtils.isPolicyAdmin(props.policy); Additional NoteWe should also do this for settings like What other approach did you explore |
Looks like something related to As a reminder, please make sure that all proposals are not workarounds and that any and all attempt to fix the issue holistically have been made before proceeding with a solution. Proposals to change our Feel free to drop a note in #expensify-open-source with any questions. |
Triggered auto assignment to @puneetlath ( |
Bug0 Triage Checklist (Main S/O)
|
ProposalPlease re-state the problem that we are trying to solve in this issue.Web - UserB can access the room "Welcome message" page and update it without permission What is the root cause of that problem?In current What changes do you think we should make in order to solve the problem?Since we need to reuse this in few other places, the best way to reuse the logic is to write a HOC. Let's call it import PropTypes from 'prop-types';
import React from 'react';
import {withOnyx} from 'react-native-onyx';
import _ from 'underscore';
import getComponentDisplayName from '../../../libs/getComponentDisplayName';
import NotFoundPage from '../../ErrorPage/NotFoundPage';
import ONYXKEYS from '../../../ONYXKEYS';
import reportPropTypes from '../../reportPropTypes';
import FullscreenLoadingIndicator from '../../../components/FullscreenLoadingIndicator';
import * as ReportUtils from '../../../libs/ReportUtils';
import * as PolicyUtils from "../../../libs/PolicyUtils";
export default function (WrappedComponent) {
const propTypes = {
/** The HOC takes an optional ref as a prop and passes it as a ref to the wrapped component.
* That way, if a ref is passed to a component wrapped in the HOC, the ref is a reference to the wrapped component, not the HOC. */
forwardedRef: PropTypes.func,
/** The report currently being looked at */
report: reportPropTypes,
/** The policies which the user has access to */
policies: PropTypes.objectOf(
PropTypes.shape({
/** The policy name */
name: PropTypes.string,
/** The type of the policy */
type: PropTypes.string,
}),
),
/** Beta features list */
betas: PropTypes.arrayOf(PropTypes.string),
/** Indicated whether the report data is loading */
isLoadingReportData: PropTypes.bool,
};
const defaultProps = {
forwardedRef: () => {},
report: {},
policies: {},
betas: [],
isLoadingReportData: true,
};
// eslint-disable-next-line rulesdir/no-negated-variables
function WithPolicyAdmin(props) {
if (props.isLoadingReportData && (_.isEmpty(props.report) || !props.report.reportID)) {
return <FullscreenLoadingIndicator />;
}
// if we don't have permission, show not found page.
if (_.isEmpty(props.report) || !props.report.reportID || !ReportUtils.canAccessReport(props.report, props.policies, props.betas) || !PolicyUtils.isPolicyAdmin(props.policy)) {
return <NotFoundPage />;
}
const rest = _.omit(props, ['forwardedRef']);
return (
<WrappedComponent
// eslint-disable-next-line react/jsx-props-no-spreading
{...rest}
ref={props.forwardedRef}
/>
);
}
WithPolicyAdmin.propTypes = propTypes;
WithPolicyAdmin.defaultProps = defaultProps;
WithPolicyAdmin.displayName = `withPolicyAdmin(${getComponentDisplayName(WrappedComponent)})`;
// eslint-disable-next-line rulesdir/no-negated-variables
const withPolicyAdmin = React.forwardRef((props, ref) => (
<WithPolicyAdmin
// eslint-disable-next-line react/jsx-props-no-spreading
{...props}
forwardedRef={ref}
/>
));
return withOnyx({
report: {
key: ({route}) => `${ONYXKEYS.COLLECTION.REPORT}${route.params.reportID}`,
},
isLoadingReportData: {
key: ONYXKEYS.IS_LOADING_REPORT_DATA,
},
betas: {
key: ONYXKEYS.BETAS,
},
policies: {
key: ONYXKEYS.COLLECTION.POLICY,
},
})(withPolicyAdmin);
} Since this logic will cover What alternative solutions did you explore? (Optional)N/A |
Interesting. I agree that we need to restrict this from both the front-end and back-end. |
Job added to Upwork: https://www.upwork.com/jobs/~0112e180fbc88a066d |
Current assignee @puneetlath is eligible for the External assigner, not assigning anyone new. |
Triggered auto assignment to Contributor-plus team member for initial proposal review - @mollfpr ( |
@mollfpr thoughts on the proposal? |
Reviewing now! |
Just a note that we are trying to move away from HOCs with the typescript migration as mentioned here: https://expensify.slack.com/archives/C01GTK53T8Q/p1688768735041469?thread_ts=1688768338.846769&channel=C01GTK53T8Q&message_ts=1688768735.041469 |
Thanks for the proposal guys! The HOC seems tempting and can do the conditional rendering. But this is pretty simple checking, and I am okay with doing it on each component page. As mentioned before by @esh-g, we are trying to move away from HOCs, and migrating to typescript will give us a headache 😅 So the proposal from @esh-g looks good. I think showing the not found page seems good. Also, we should update the 🎀 👀 🎀 C+ reviewed! |
Triggered auto assignment to @grgia, see https://stackoverflow.com/c/expensify/questions/7972 for more details. |
Cool, I agreed with ya about the HOC. Since |
Well played @hungvu193 👍 |
📣 @mollfpr 🎉 An offer has been automatically sent to your Upwork account for the Reviewer role 🎉 Thanks for contributing to the Expensify app! |
📣 @esh-g 🎉 An offer has been automatically sent to your Upwork account for the Contributor role 🎉 Thanks for contributing to the Expensify app! Upwork job |
📣 @ayazhussain79 We're missing your Upwork ID to automatically send you an offer for the Reporter role. |
|
The solution for this issue has been 🚀 deployed to production 🚀 in version 1.3.42-26 and is now subject to a 7-day regression period 📆. Here is the list of pull requests that resolve this issue: If no regressions arise, payment will be issued on 2023-07-26. 🎊 After the hold period is over and BZ checklist items are completed, please complete any of the applicable payments for this issue, and check them off once done.
As a reminder, here are the bonuses/penalties that should be applied for any External issue:
|
BugZero Checklist: The PR fixing this issue has been merged! The following checklist (instructions) will need to be completed before the issue can be closed:
|
Looks like everyone has had contracts sent. @mollfpr friendly reminder on the checklist. |
Issue reporter: @ayazhussain79 $250 I've paid the first two. @mollfpr just waiting on the checklist for you. |
Sorry, I swear I already complete the checklist of the issues near the payment date 😅
https://github.com/Expensify/App/pull/18662/files#r1278793008
The regression step should be enough.
Test Setup
Therefore, B is an admin in workspace B and not workspace A. We need to prepare a chat with deep links to the correct page for testing. This setup can be done once on web, and then can be tested on other platforms with the same account. ✅ The page will open
|
Great, thanks. Paid! |
If you haven’t already, check out our contributing guidelines for onboarding and email [email protected] to request to join our Slack channel!
Action Performed:
Expected Result:
UserB should be unable to access the "Welcome message" page and should not be able to modify it
Actual Result:
UserB can access the "Welcome message" page and update it without permission
Workaround:
Unknown
Platforms:
Which of our officially supported platforms is this issue occurring on?
Version Number: 1.3.34-1
Reproducible in staging?: y
Reproducible in production?: y
If this was caught during regression testing, add the test name, ID and link from TestRail:
Email or phone of affected tester (no customers):
Logs: https://stackoverflow.com/c/expensify/questions/4856
Notes/Photos/Videos: Any additional supporting documentation
screen-recording-2023-06-30-at-125608-am_4BuHkCsb.1.mp4
Recording.5257.mp4
Expensify/Expensify Issue URL:
Issue reported by: @ayazhussain79
Slack conversation: https://expensify.slack.com/archives/C049HHMV9SM/p1688069999157569
View all open jobs on GitHub
Upwork Automation - Do Not Edit
The text was updated successfully, but these errors were encountered: