Hi Juan Pablo, Thanks for the references. In looking over the notes to JSPWIKI-155, in particular, I believe the EntityManager approach provides a mitigating solution to what is I agree a security hole big enough to drive a truck through (notwithstanding that plugins can do anything anyway, but users/installers have the choice of uninstalling plugins they don't want present, whereas this is at the core of the application).
Given what I've accomplished so far is to refactor a lot of the managers as implementations of new interfaces and instantiating them via the EntityManager, it might be possible for someone to without *too* much effort incorporate the code into the existing trunk; then anyone could continue along that track in the future. I'll see if I can over the next week do a cleanup and attach either a patch or a zip of the code to the issue. Ichiro On Fri, Sep 6, 2013 at 6:09 AM, Juan Pablo Santos RodrÃguez < juanpablo.san...@gmail.com> wrote: > Hi Ichiro, > > I'm +1 with Glen, https://issues.apache.org/jira/browse/JSPWIKI-155 or > https://issues.apache.org/jira/browse/JSPWIKI-303 might be good candidates > to attach the tar/patch to > > > thx for your time on looking into this + br, > juan pablo > > > > On Thu, Sep 5, 2013 at 3:22 AM, Glen Mazza <glen.ma...@gmail.com> wrote: > > > Hi Ichiro, yes, please keep your work, someone may wish to look at it in > > the future. (Perhaps you can enter it as a JIRA as an enhancement > request > > and supply a patch giving a general idea of what you're thinking about.) > > My time is now also constrained due to other needs and it may be awhile > > before I can do much for JSPWiki. (Also, Harry, I'm not sure when I can > > look at the ehcache stuff, I would go ahead with it if it seems good to > > you.) > > > > Regards, > > Glen > > > > > > On 09/04/2013 07:44 AM, Ichiro Furusato wrote: > > > >> Hi, > >> > >> I've recently found that the window I thought I had to do some extra > work > >> has disappeared, > >> such that the EntityManager work has been put on hold indefinitely. I'd > >> hoped Murray might > >> be able to pick some of this up but he's tied up as well. > >> > >> I had got to the point where I'd modified WikiEngine to instantiate most > >> of > >> the managers > >> from the EntityManager following a bootstrap load of them via a config > >> file. The WikiEngine > >> then simply grabs them from the EntityManager. The idea was to gradually > >> remove > >> unnecessary references in WikiEngine and force the rest of the > application > >> to obtain the > >> managers from the EntityManager's map via their string identifiers, with > >> restrictions on that > >> access set via the EntityManager's config. > >> > >> I'd ideally like to finish this but I simply don't know when I'll have > >> time > >> -- it's not looking I will > >> prior to Christmas at this point. My apologies for not being able to > >> deliver this work -- I > >> believe it represents a simpler and cleaner way to start up the > >> application. As JSPWiki has > >> gotten more complicated over the years it's just seemed to burden the > >> engine with too much > >> baggage. An EntityManager (or "ManagerManager") seems like an > appropriate > >> solution. > >> > >> If anyone is interested in this work I'm happy to post a tarball and > >> provide its location. > >> > >> Cheers, > >> > >> Ichiro > >> > >> > >> On Tue, Jul 9, 2013 at 8:52 PM, Ichiro Furusato > >> <ichiro.furus...@gmail.com>**wrote: > >> > >> Hi, > >>> > >>> I'm in the middle of working through some new manager classes as a > >>> supplement to JSPWiki. These managers will be singletons similar to > >>> the dozen or so existing managers that get instantiated in the method > >>> WikiEngine.initialize(), such as the PageManager, PluginManager, etc. > >>> > >>> The following is *not* a commitment to work, it is an offer to share > the > >>> results if I'm able to (a) find the time to finish it; and (b) I can > make > >>> it > >>> work; and (c) people are interested. I'm seeking feedback about the > >>> proposed design. I'm not currently a team member but I could pass the > >>> code or patches on to someone to check in if necessary. > >>> > >>> What I'm considering is potentially a solution to the note in that > method > >>> concerning the "unwieldy" nature of the current approach of building > the > >>> WikiEngine's managers, namely a new EntityManager that would > >>> sequentially create all the current managers according to a > configuration > >>> file, such that each manager (entity) could then be referred to by > name. > >>> This would also permit additional entities (like my new manager) to be > >>> added and subsequently referred to by name. > >>> > >>> The only thing one would need to gain access to the EntityManager would > >>> be the WikiEngine itself -- all other managers would therefore be > >>> available > >>> by name and all of the existing getter methods could be deprecated and > >>> eventually the WikiEngine would therefore be simplified. The WikiEngine > >>> would spawn a singleton EntityManager and then let it handle access to > >>> those entities. > >>> > >>> The configuration for the EntityManager would be an XML file, where > >>> each individual entity configuration would include the following > >>> parameters: > >>> > >>> * identifier (package name) of the entity > >>> > >>> * boot order parameter (1-n) OR order in file is used. > >>> > >>> * boolean stating whether the entity can be modified/replaced > >>> once created > >>> > >>> * access modifiers suggesting permitted access to the entity: > >>> 'private' : only to the WikiEngine itself > >>> 'protected' : only to org.apache.wiki.* code > >>> 'public' : open access > >>> [not sure how to do this but could get some advice from one of > >>> the team's security experts] > >>> > >>> * anything else? > >>> > >>> This would obviously involve a substantial rewiring of the engine and > >>> current managers, as they tend to gain access to each other via the > >>> WikiEngine, hence the idea of deprecating the existing methods in > >>> WikiEngine (and implementing their current getters via the > EntityManager) > >>> rather than eliminating them outright. Once done though, this would > >>> greatly simplify the WikiEngine itself. It basically would have a new > >>> bootstrap manager. > >>> > >>> To give you an idea of what problem I'm trying to solve, we're > currently > >>> developing an updated TagManager based on Murray Altheim's existing > >>> TagPlugin (and related features) to provide a tagging solution for > >>> JSPWiki, as well as a GroovyService to provide a wiki-related Groovy > >>> scripting solution, supporting an update to our older GroovyPlugin but > >>> also permitting a wiki page-based command console (obviously not for > >>> use on public wikis). You'd have a on-page form as a console drawing > >>> upon a 'bin' directory of Groovy scripts, basically a file-based DSL > over > >>> Groovy command line functionality. So you could write a HelloWorld.grv > >>> file, put it in the WEB-INF/bin directory and be able to type > >>> 'HelloWorld' > >>> into the console command line. That kind of thing. We have this mostly > >>> working already so this is basically a way to add a new manager > >>> without either adding a getter to the WikiEngine or gaining access via > >>> some singleton trickery. > >>> > >>> If this sounds palatable to the group I'll go ahead and begin coding in > >>> mind of it being a public effort (with appropriate Apache license > headers > >>> in the files, etc.), otherwise I'll build it as an addon for our own > >>> local > >>> use. > >>> > >>> I would like to know one question if I do begin: should I simply work > on > >>> the trunk or would this be better as a branch? If so I'd need someone > to > >>> create that branch. > >>> > >>> If I end up running out of steam I might want some help, particularly > on > >>> the security-related stuff since that's not my forte. If anyone is up > for > >>> helping in this regard please let me know. > >>> > >>> Cheers, > >>> > >>> Ichiro > >>> > >>> > >>> > >>> > > >
