-
Notifications
You must be signed in to change notification settings - Fork 16
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
fix: check authorities in app adapter [LIBS-370] #757
Conversation
// Skip check on dev | ||
// TODO: should we check on dev environments too? | ||
if (!IS_PRODUCTION_ENV) { | ||
return 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.
Curious what others think -- most app devs probably have admin privileges, but if they don't have app management authority, it's possible that someone might end up working on an a new app which they don't have authorities for.
Someone might be able to bypass their authorities limitations by running an app locally though?...
Currently I guess we don't do any checks like this
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.
(You can make testing easier by commenting out the return true
to run it on dev)
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 initially wasn't sold on the idea of always returning true in a development environment, but think I'm coming around to it.
Full reload | From SW | |
---|---|---|
Production | Server renders no-access page | App-shell renders no-access view |
Development | Dev can access app | Dev can access app |
This is actually very consistent and I like it.
cli/src/lib/formatAppAuthName.js
Outdated
if (config.coreApp) { | ||
// TODO: Verify this formatting - are there any transformations, | ||
// or do we trust that it's lower-case and hyphenated? | ||
return APP_AUTH_PREFIX + DHIS_WEB + config.name | ||
} |
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.
Curious about whether this formatting of core app names is correct?
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 the user app I am also inferring specific types of authorities based on their naming scheme. This has been in production for about 4 years now, so this suggests to me the naming scheme is consistent enough. You can also review the response of this requests: https://play.dhis2.org/dev/api/40/authorities?fields=id,name&paging=false
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.
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.
Ah I see we're doing that below - but we should also do it for core apps.
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, notice that the formatting is different between those two things you linked, namely around hyphens -- core apps seem to be getting a different treatment? But I didn't find what exactly it is
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.
Added some formatting insurance in this commit
if (response.type === 'opaqueredirect' || !response.ok) { | ||
// It's sending a redirect to the login page, | ||
// or an 'unauthorized'/'forbidden' response. | ||
// Return that to the client | ||
return 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.
Pass 403 responses to the client in production, instead of returning index.html
const IS_PRODUCTION_ENV = process.env.NODE_ENV === 'production' | ||
|
||
const APP_MANAGER_AUTHORITY = 'M_dhis-web-maintenance-appmanager' | ||
const REQUIRED_APP_AUTHORITY = process.env.REACT_APP_DHIS2_APP_AUTH_NAME |
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.
Added in CLI
You can test the boundary by logging in as a guest user (user guest, pass Guest123), which shouldn't have access to all apps -- also see the 'production env' test above that you can comment out to test it in a dev environment locally |
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.
Looks very Kai. Thanks for noticing this had slipped through the cracks and turning this around so quickly. I've left a few comments.
cli/src/lib/formatAppAuthName.js
Outdated
if (config.coreApp) { | ||
// TODO: Verify this formatting - are there any transformations, | ||
// or do we trust that it's lower-case and hyphenated? | ||
return APP_AUTH_PREFIX + DHIS_WEB + config.name | ||
} |
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 the user app I am also inferring specific types of authorities based on their naming scheme. This has been in production for about 4 years now, so this suggests to me the naming scheme is consistent enough. You can also review the response of this requests: https://play.dhis2.org/dev/api/40/authorities?fields=id,name&paging=false
@KaiVandivier there is quite a bit of overlap here with #754 by the way |
@amcgee I noticed that -- I refactored the app wrapper in my latest commit to work well with the changes that you have here: https://github.com/dhis2/app-platform/pull/754/files#diff-58fcbeed2ec3103f3d186cb172bf2da570e316e008fb614240d6aa0f72df7574 Taking a closer look now though |
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.
Would be good to not duplicate logic between this and the session expiration PR
cli/src/lib/formatAppAuthName.js
Outdated
if (config.coreApp) { | ||
// TODO: Verify this formatting - are there any transformations, | ||
// or do we trust that it's lower-case and hyphenated? | ||
return APP_AUTH_PREFIX + DHIS_WEB + config.name | ||
} |
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.
cli/src/lib/formatAppAuthName.js
Outdated
if (config.coreApp) { | ||
// TODO: Verify this formatting - are there any transformations, | ||
// or do we trust that it's lower-case and hyphenated? | ||
return APP_AUTH_PREFIX + DHIS_WEB + config.name | ||
} |
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.
Ah I see we're doing that below - but we should also do it for core apps.
Also added handling for server versions < 35, as in https://github.com/dhis2/app-platform/blob/fix/pwa-handle-navigations/cli/src/lib/constructAppUrl.js#L8 |
Drafted while this is on the back-burner |
I think concerns have been addressed and this is ready for rereview @amcgee |
Closing since this is stagnant to clean up open PRs -- can be reopened if needed. This may be relevant to the global shell |
Address LIBS-370
Includes the fixes for LIBS-356 and LIBS-357 (which were split off from here and merged in separate PRs)
Checks authorization on the client side by using an AuthBoundary component to check correct authorities and block the app if necessary. This is needed because some deployment environments don't return a 403 'Forbidden' response (like standalone deployments and Netlify, it seems)
Todo:
UI Draft, updated: