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
Vaadin OSGi applications should not expose relevant classpath content as static resources #50
Comments
|
This is partially an issue in overall OSGi HTTP whiteboard implementation (not sure about specification) and Vaadin:
Vaadin behavior is the same regardless servlet container. But the first behavior is quite specific for OSGi: one has to do an explicit action/configuration to include resources available via Unfortunately there is no easy way to fix this: if we disable serving resources available via In fact there is already existing solution for this (even though it's not obvious that it's always "required" with Vaadin): a custom So there is already a solution for this but it requires additional class and complicates the servlet registration: every servlet should be registered using some On the other hand it's quite easy to expose any classpath resource via Resource service, so there is no need to expose automatically everything available via |
I agree with you. But by sentence says totally different thing. |
refactor: use StaticFileHandler as a service Part of vaadin/osgi#50
refactor: use StaticFileHandler as a service Part of vaadin/osgi#50
* refactor: use StaticFileHandler as a service (#10229) Part of vaadin/osgi#50
* fix: implement static file handler factory for OSGi fixes #50
ServletContext resources are not available anymore via HTTP after vaadin/osgi#50. So they should be exposed explicitly via resource service
@denis-anisimov it seems that the |
|
The sentence targets the resources availability via |
|
Ok. Both me and Artem were able to access the manifest file. I'll edit the comment so nobody has any misunderstanding. |
ServletContext resources are not available anymore via HTTP after vaadin/osgi#50. So they should be exposed explicitly via resource service
ServletContext resources are not available anymore via HTTP after vaadin/osgi#50. So they should be exposed explicitly via resource service Co-authored-by: Denis Anisimov <denis@vaadin.com>
* A new default branch with a stable version * Update repository tag in pom (#16) * fixed gitignore file for the project (#22) Co-authored-by: Matti Tahvonen <matti@vaadin.com> * version update (#23) * Update Vaadin to 19.0.4 (#30) * Fix regression with static resources (#31) * Revert "Fix regression with static resources (#31)" (#32) This reverts commit 93b9647. * chore: expose static resources explicitly (#34) ServletContext resources are not available anymore via HTTP after vaadin/osgi#50. So they should be exposed explicitly via resource service Co-authored-by: Denis Anisimov <denis@vaadin.com> * Add issue template (#29) (#38) * Update Vaadin to 19.0.5 (#39) * Update to use Java 11 * Separate module for greetservice api * Update to use Java 11 * Avoid issues with Java 11 modules * Proper export package hint for bdn * Make the project use Java 11 (#41) * Update to use Java 11 * Avoid issues with Java 11 modules * Validation build for the project for all PRs (#42) * Update to use Java 11 * Avoid issues with Java 11 modules * Added a GitHub actions based test that build passes * Added a missing pom.xml Co-authored-by: Zhe Sun <31067185+ZheSun88@users.noreply.github.com> Co-authored-by: Vaadin Bot <vaadin-bot@users.noreply.github.com> Co-authored-by: Denis <denis@vaadin.com>
In our OSGi examples (https://github.com/vaadin/base-starter-flow-osgi & https://github.com/vaadin/base-starter-flow-karaf) class files and other resources can be accessed from the main bundles. This is unexpected behaviour from the end users point of view and can be considered a bad practise.
We should either change the implementation of our integration code so that generic content from bundle(s) is not served or change the examples so that only minimal and security wise safe content is exposed.
If we only change our examples, it should be documented that all resources (including class files) from the bundle that is registering the servlet are exposed.
The text was updated successfully, but these errors were encountered: