Honestly, i'm content either way, this doesn't much affect me. So, whatever y'all think is best works for me.
On Wed, Apr 25, 2018 at 12:54 AM, Claude Brisson <cla...@renegat.net.invalid > wrote: > Any thoughts on this? From my side, apart from this potential point, the > tools are ready. > > Claude > > > > On 22/03/2018 01:25, Claude Brisson wrote: > >> Yes, it'd be great to soon release the tools since the engine is out. >> >> And yes, autoconfig hasn't to be the default. Why not starting with an >> empty toolbox by default if it eases things for integrators. But there are >> two different things here: >> 1) *default* tools (loaded from tools.xml files inside each >> velocity-tools jar) >> 2) *standard* user toolbox configuration files >> >> For 1), what about a "load-default-tools" param in the descriptor? (As >> usual, we would first check init-params for the concerned servlet/filter >> and then, if not found, the context-params). It can be false by default for >> 3.0, if you guys think that that's the way to go. As long as we diligently >> document it when releasing. >> >> For 2), I'm pretty sure no standard configuration file should be ever >> checked if an explicit configuration is provided, of course (but, by the >> way, why is it problematic whenever those files aren't there? Oh, I see, >> the SecurityManager doesn't want me to read files that do not exist, funny >> but perfectly logical). Would it be harmful to still check for those >> standard locations whenever no explicit location is given be harmful (other >> than itching the SecurityManager)? >> >> So if I understand correctly, we *also* need to use PrivilegedActions. >> Does it boils down to wrapping system calls in >> AccessController.doPrivileged() calls? Where and how are those calls >> authorized? Sorry, I never used the PrivilegedActions and SecurityManager >> paradigm yet. If you have some good pointers or suggestions... >> >> I don't really understand either why we're speaking of the CWD whereas >> all the VelocityView knows is the webapp root. But I may have missed >> something. >> >> >> Claude >> >> On 21/03/2018 22:23, Nathan Bubna wrote: >> >>> If we're talking 2.x, then adding a PrivilegedAction sounds better. If >>> 3.0 >>> (which, i think needs to happen anyway, right Claude?), then i'd agree >>> with >>> Michael. The auto config would be better off as something users need to >>> explicitly turn on, not the default any longer. >>> >>> On Wed, Mar 21, 2018 at 2:03 PM, Michael Osipov <micha...@apache.org> >>> wrote: >>> >>> Am 2018-03-21 um 06:17 schrieb Christopher Schultz: >>>> >>>> All, >>>>> >>>>> Using velocity-tools 2.0. >>>>> >>>>> I've been exploring what it takes to get my application working under a >>>>> SecurityManager and it seems that o.a.v.t.view.VelocityView tries to >>>>> load a few configuration files from their default locations even when a >>>>> specific configuration file has been specified by a subclass like >>>>> VelocityLayoutServlet: >>>>> >>>>> <servlet> >>>>> <servlet-name>velocity</servlet-name> >>>>> <servlet-class> >>>>> com.chadis.web.servlet.VelocityLayoutServlet >>>>> </servlet-class> >>>>> >>>>> <init-param> >>>>> <param-name>org.apache.velocity.tools</param-name> >>>>> <param-value>/WEB-INF/tools.xml</param-value> >>>>> </init-param> >>>>> ... >>>>> >>>>> >>>>> What ends up happening is that VelocityView checks for the default >>>>> configuration files tools.xml and tools.properties (in the current >>>>> working directory) and so FilePermissions must be given to the whole >>>>> JVM >>>>> -- because VelocityView (or ConfigurationUtils) doesn't make the >>>>> attempt >>>>> in a PrivilegedAction. >>>>> >>>>> I think this can be done in a more friendly way, but I'm not sure what >>>>> is best for the community. >>>>> >>>>> We could add a PrivilegedAction to the mix when a SecurityManager is >>>>> present. This way, the velocity library could be granted read access to >>>>> these specific files (instead of the whole JVM). This would impact the >>>>> smallest number of users. >>>>> >>>>> We could remove the attempts to load these configuration files out of >>>>> the CWD. This would probably affect the largest number of users >>>>> (although relying on the CWD to find a default configuration file is >>>>> ... >>>>> bad practice). >>>>> >>>>> Or we could change the way Velocity*Servlet use VelocityView so that >>>>> default configuration files are only loaded when there is no explicit >>>>> configuration file. >>>>> >>>>> Thoughts? >>>>> >>>>> Personally, I was never a huge fan of this autoconfig. It was overly >>>> comples. A few only understood. This also lead to subtile bugs which >>>> Maven >>>> Doxia leaving them open for years which I finally fixed last year. >>>> >>>> I would personally expact an empty toolbox present, if nothing has been >>>> configured by the user. Even if this will break stuff, we can do so for >>>> 3.0 >>>> with ease. See https://issues.apache.org/jira/browse/DOXIASITETOOLS-93. >>>> >>>> Michael >>>> >>>> --------------------------------------------------------------------- >>>> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org >>>> For additional commands, e-mail: dev-h...@velocity.apache.org >>>> >>>> >>>> >> >> --------------------------------------------------------------------- >> To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org >> For additional commands, e-mail: dev-h...@velocity.apache.org >> >> >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@velocity.apache.org > For additional commands, e-mail: dev-h...@velocity.apache.org > >
