You are viewing a plain text version of this content. The canonical link for it is here.
Posted to issues@nifi.apache.org by GitBox <gi...@apache.org> on 2020/11/12 22:49:06 UTC
[GitHub] [nifi] thenatog opened a new pull request #4659: NIFI-7870 - Added an allow list for static resources so that they can…
thenatog opened a new pull request #4659:
URL: https://github.com/apache/nifi/pull/4659
… be accessed anonymously.
NIFI-7870 - Fixed test verbiage.
NIFI-7870 - Added license headers. Checkstyle fix.
Thank you for submitting a contribution to Apache NiFi.
Please provide a short description of the PR here:
#### Description of PR
_Enables X functionality; fixes bug NIFI-YYYY._
In order to streamline the review of the contribution we ask you
to ensure the following steps have been taken:
### For all changes:
- [x] Is there a JIRA ticket associated with this PR? Is it referenced
in the commit message?
- [x] Does your PR title start with **NIFI-XXXX** where XXXX is the JIRA number you are trying to resolve? Pay particular attention to the hyphen "-" character.
- [x] Has your PR been rebased against the latest commit within the target branch (typically `main`)?
- [x] Is your initial contribution a single, squashed commit? _Additional commits in response to PR reviewer feedback should be made on this branch and pushed to allow change tracking. Do not `squash` or use `--force` when pushing to allow for clean monitoring of changes._
### For code changes:
- [x] Have you ensured that the full suite of tests is executed via `mvn -Pcontrib-check clean install` at the root `nifi` folder?
- [x] Have you written or updated unit tests to verify your changes?
- [x] Have you verified that the full build is successful on JDK 8?
- [x] Have you verified that the full build is successful on JDK 11?
- [ ] If adding new dependencies to the code, are these dependencies licensed in a way that is compatible for inclusion under [ASF 2.0](http://www.apache.org/legal/resolved.html#category-a)?
- [ ] If applicable, have you updated the `LICENSE` file, including the main `LICENSE` file under `nifi-assembly`?
- [ ] If applicable, have you updated the `NOTICE` file, including the main `NOTICE` file found under `nifi-assembly`?
- [ ] If adding new Properties, have you added `.displayName` in addition to .name (programmatic access) for each of the new properties?
### For documentation related changes:
- [ ] Have you ensured that format looks appropriate for the output in which it is rendered?
### Note:
Please ensure that once the PR is submitted, you check GitHub Actions CI for build issues and submit an update to your PR as soon as possible.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] thenatog commented on pull request #4659: NIFI-7870 - Added an allow list for static resources so that they can…
Posted by GitBox <gi...@apache.org>.
thenatog commented on pull request #4659:
URL: https://github.com/apache/nifi/pull/4659#issuecomment-772576362
Closing this PR with the goal of creating a better solution.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] thenatog commented on pull request #4659: NIFI-7870 - Added an allow list for static resources so that they can…
Posted by GitBox <gi...@apache.org>.
thenatog commented on pull request #4659:
URL: https://github.com/apache/nifi/pull/4659#issuecomment-726389414
Interested in feedback on this one, let me know if you think the allow list is too long, and if the checking that I'm doing against the list is sufficiently robust.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] thenatog commented on pull request #4659: NIFI-7870 - Added an allow list for static resources so that they can…
Posted by GitBox <gi...@apache.org>.
thenatog commented on pull request #4659:
URL: https://github.com/apache/nifi/pull/4659#issuecomment-726836856
I tend to agree. Maybe we can discuss using a cookie in combination with an authorization header to avoid breaking backwards compatibility but getting the benefit of using the cookie. This would, I think, eventually remove the need for a few different parts of code like the OTP for downloads and perhaps others where we've had to do a bit of extra work to use an authorization header.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] bbende commented on pull request #4659: NIFI-7870 - Added an allow list for static resources so that they can…
Posted by GitBox <gi...@apache.org>.
bbende commented on pull request #4659:
URL: https://github.com/apache/nifi/pull/4659#issuecomment-726796835
I feel like maintaining this list is going to be very challenging, how would anyone know to update this?
The most correct solution to me would be for us to use a Cookie for the interacts between NiFi UI and the REST API, this way the credentials are submitted on all requests, similar to how a client certificate is automatically submitted. We would still want to support the current Authorization header approach for direct API access.
If we have a good reason for not doing that, and we still want to pursue some type of allow list, could it be done with some kind of patterns? Not sure if all the front-end stuff comes from some base path that we could just allow anything that starts with the base path, or maybe use extensions and say that we allow any .html, .css, .js, etc.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] exceptionfactory commented on pull request #4659: NIFI-7870 - Added an allow list for static resources so that they can…
Posted by GitBox <gi...@apache.org>.
exceptionfactory commented on pull request #4659:
URL: https://github.com/apache/nifi/pull/4659#issuecomment-730102313
Concurring with @bbende that maintaining a static list of allowed files seems very brittle. At minimum, using a much smaller set of regular expression patterns would be easier to maintain. If the goal is to avoid pattern matching at runtime, perhaps introducing something in the build process to find static resources and generate a list could be considered.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] thenatog closed pull request #4659: NIFI-7870 - Added an allow list for static resources so that they can…
Posted by GitBox <gi...@apache.org>.
thenatog closed pull request #4659:
URL: https://github.com/apache/nifi/pull/4659
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org
[GitHub] [nifi] thenatog commented on pull request #4659: NIFI-7870 - Added an allow list for static resources so that they can…
Posted by GitBox <gi...@apache.org>.
thenatog commented on pull request #4659:
URL: https://github.com/apache/nifi/pull/4659#issuecomment-729875887
I think the plan here was that, for the bundled advanced UIs, they could exist in this list and be granted anonymous access. For custom advanced UIs that the community may develop/use, they will need to be accessed anonymously by enabling the "nifi.security.allow.anonymous.authentication" property. This reduces the list maintenance requirement a little bit, but does not eliminate it. It's possible that the list could be cut down by my manually looking at the resources that need to be allowed, in the UI, to check what is not accessible and enabling only those. From memory it was at least a few CSS files that caused the bigger issues. As far as wildcarding some of this, it was recommended to be explicit on the file name and not to use patterns. Maybe we can get @alopresto to chime in and see what he thinks of my approach to this PR.
Having said that, I do believe that moving towards using a cookie for storing the JWT in the browser may be a reasonable option. I've been researching the benefits vs risks, the details of which I'm still collating. It would eliminate a few parts of code that we've so far had to implement as a side effect of using an explicit authorization header.
----------------------------------------------------------------
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
users@infra.apache.org