Hi, I agree with Denis, this is not the solution ; and yes it's different from having all master wiki documents with XWiki.Admin as author, since on a farm you don't necessarily control the sub wikis, while you control the master one (it's rights settings, the apps installed, etc.). Myxwiki.org is a good example.
I don't know Workspaces yet, but indeed we have a problem when using XE .xar in XEM sub-wikis: it's not adapted. In my opinion we should provide a "template wiki" xar too. For the record and on the top of my head, here is what I do on the template wiki (so it's the same as crafting a template XAR) when I install XEM * delete XWiki.Admin * delete wiki macros (activity, spaces, tag cloud etc.) -and change the scope of the corresponding ones in the "master" wiki to global ; AND for some macro you have to delete just the object, not the whole document because they have SX in it and cross-wiki SX are not supported. I might be forgetting some other actions... Jerome On Thu, Dec 15, 2011 at 3:33 PM, Denis Gervalle <[email protected]> wrote: > Hi Eduard, > > On Thu, Dec 15, 2011 at 14:30, Eduard Moraru <[email protected]> wrote: > >> Hi Denis, >> >> Why is this a security issue and how is this different from importing a xar >> in the main wiki (where XWiki.Admin has PR and everything)? >> > > I am simply against this idea since it is for me exactly the same as using > Windows as an administrator since using it as a normal user is a pain. If > the xar is properly setup, there is no reason it would fail with the issue > you mention. > > >> The issue at hand is not about setting the current user as author for any >> import done in a wiki. It`s about doing so just for a wiki template, when >> creating it from a template xar. The template xar that you are using is the >> one you have very carefully composed and approved (as a global admin). It >> > > I am a wiki admin, but I am never sure, even after careful inspection that > any pages on a given wiki could gain PR without causing a risk. > > >> is not a random application's xar that you are importing at wiki template >> creation time. Most of the time you are going to use a XE xar anyway which >> has XWiki.Admin everywhere and that is causing some problems that this >> change will fix. >> > > I agree with you that the xar we produce are not setup properly for farm > purpose, but I was using farm for years now, and I have simply properly > setup my templates. Importing the author of document allows to carefully > provide programming writes only on documents that need them. If you also > prevent normal user to save it, you became really safe. > > Moreover, you may also include some users in your template and precisely > set them as authors of some document for very legitimate purpose. > > >> Please provide some additional arguments for your -1. This issue is >> currently breaking things in Workspaces. >> > > For me, your focusing too much on the Workspace situation, and I do not > understand why you need that for workspace ? If you xar is well prepared, > it should simply works properly without this proposal. > > Thanks, >> Eduard >> >> On Thu, Dec 15, 2011 at 2:48 PM, Denis Gervalle <[email protected]> wrote: >> >> > -1, this would be an obvious security issue and it is worse than simply >> > ensuring proper authoring in the template where needed. >> > >> > Denis >> > >> > On Wed, Dec 14, 2011 at 22:06, Eduard Moraru <[email protected]> >> wrote: >> > >> > > Hi devs, >> > > >> > > Right now, when you create a wiki template from a xar, the import that >> is >> > > done in the background is a backup import, meaning that the last author >> > of >> > > the pages that get imported in the new wiki keep the author specified >> by >> > > the xar. This often creates problems like: >> > > - Missing Programming Rights >> > > - Unregistered macros >> > > - Malfunctioning scripts >> > > >> > > These problems can appear because the user specified in the xar (even >> if >> > it >> > > is XWiki.Admin) is almost always a local user and subwiki local users >> do >> > > not have PR. >> > > If it's not a PR issue, then the user specified in the xar can be >> > > non-existent and this makes admin checks fail, thus failing wiki macro >> > > registration for the entire subwiki. >> > > >> > > We are currently experiencing this problem in Workspaces, since, at the >> > > install step, we create a workspace template by using a >> > > workspace-template.xar (default XE but can also be user provided). >> Since >> > we >> > > make sure to delete any local users (including XWiki.Admin), the Wiki >> > > macros will not be registered in the template and, obviously, neither >> in >> > > any created workspace. >> > > >> > > I`m hoping to include this in 3.3 final so that Workspaces can avoid >> the >> > > macro registration problems (and possibly others). >> > > >> > > So I`m asking for your vote to change the current default to >> non-backup. >> > > This means that all the pages in the new subwiki template will have the >> > > current admin user that created the template as last author. >> > > >> > > Here's my +1. >> > > >> > > Thanks, >> > > Eduard >> > > _______________________________________________ >> > > devs mailing list >> > > [email protected] >> > > http://lists.xwiki.org/mailman/listinfo/devs >> > > >> > >> > >> > >> > -- >> > Denis Gervalle >> > SOFTEC sa - CEO >> > eGuilde sarl - CTO >> > _______________________________________________ >> > devs mailing list >> > [email protected] >> > http://lists.xwiki.org/mailman/listinfo/devs >> > >> _______________________________________________ >> devs mailing list >> [email protected] >> http://lists.xwiki.org/mailman/listinfo/devs >> > > > > -- > Denis Gervalle > SOFTEC sa - CEO > eGuilde sarl - CTO > _______________________________________________ > devs mailing list > [email protected] > http://lists.xwiki.org/mailman/listinfo/devs -- Jérôme Velociter Winesquare http://www.winesquare.net/ _______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
