Introduce capabilities provider and switcher to file upload plugin #96593
Conversation
|
@nreese @jgowdyelastic here's a potential solution to the file upload problem we discussed today. Let me know your thoughts! |
|
let me know if this is still needed |
Thanks @legrego for putting this PR together. This is still something very much that we are interested in. We hope to use this in the current minor sprint to make it possible to have a ingest button in the home application that will work for users without specific access to ML or maps feature privileges. I am not sure on the timing but this will be a requirement for this effort. |
legrego
added
auto-backport
| const { hasImportPermission } = await checkFileUploadPrivileges({ | ||
| authorization: security?.authz, | ||
| request, | ||
| checkCreateIndexPattern: true, | ||
| checkHasManagePipeline: false, | ||
| }); |
There was a problem hiding this comment.
We have the flexibility to change these privilege checks to whatever we need...I just picked something to start the conversation. Should we also test that the user can create pipelines?
| }); | ||
|
|
||
| core.capabilities.registerSwitcher(async (request, capabilities, useDefaultCapabilities) => { | ||
| const isAnonymousRequest = !request.route.options.authRequired; |
There was a problem hiding this comment.
question: is there any reason why we cannot use request.auth.isAuthenticated (or request.route.options.authRequired !== true && !request.auth.isAuthenticated) here instead? If authRequired === 'optional' and request is not authenticated, it seems we can treat it as a legitimate anonymous request as well.
There was a problem hiding this comment.
I wish I had a better memory -- there used to be a reason we couldn't use request.auth.isAuthenticated with the other capability switchers, but I can't remember the details. That said, it looks like the security switcher is using this very check, so maybe it's safe to do so again.
I'll experiment with this and report back!
There was a problem hiding this comment.
I modeled this switcher after the security plugin's switcher, and it appears to be working correctly!
|
|
||
| const checkPrivileges = authorizationService.checkPrivilegesDynamicallyWithRequest(request); | ||
| const checkPrivilegesResp = await checkPrivileges(checkPrivilegesPayload); | ||
| const { hasImportPermission } = await checkFileUploadPrivileges({ |
There was a problem hiding this comment.
this route (/internal/file_upload/has_import_permission) might not be needed now if we can use the capabilities on the client side in the fileDataVisualiser plugin.
but that change can be done in a follow up.
|
@elasticmachine merge upstream |
💚 Build SucceededMetrics [docs]Public APIs missing comments
Public APIs missing exports
Unknown metric groupsAPI count
References to deprecated APIs
History
To update your PR or re-run it, just comment with: |
…lastic#96593) Co-authored-by: Kibana Machine <[email protected]>
💚 Backport successful
This backport PR will be merged automatically after passing CI. |
…96593) (#100114) Co-authored-by: Kibana Machine <[email protected]> Co-authored-by: Larry Gregory <[email protected]>
…lastic#96593) Co-authored-by: Kibana Machine <[email protected]>
Summary
Adds a capabilities provider and switcher to the File Upload plugin. This provides a new
fileUpload.showUI Capability, which can be used to tell if the current user should be shown the File Upload feature.Users with the ability to create index patterns (in the current space) will be shown this feature. Users who are lacking this privilege will not be shown this feature.
^ We have the flexibility to change these privilege checks to whatever we need...I just picked something to start the conversation. Should we also test that the user can create pipelines?
The file upload plugin requires its own capabilities provider & switcher because we don't have the concept of a "composite feature" today, where it relies on both Kibana and Elasticsearch privileges in order to function. This is a limitation of the current authorization model, and is being tracked in #96598