Re: [xwiki-users] XEM and WYSIWYG

<mariusdumitru.florea(a)xwiki.com> wrote: In XE 1.8M2, the "choose a wiki" list box is *NOT* hidden and that is IMHO a problem for many setups: see the recent message I sent to the dev list, w/ subject "1.8M2: suggest public vs private v-hosting option to prevent access to other wikis." This is an issue in situations where there's separate wikis that shouldn't see each other, such as using a single box on a corporate intranet with external access to the "public" wiki, while those on the internal private network can also access the "private" wiki. The "general public" accessing from the outside internet shouldn't be able to see the spaces and document names for the entire internal private wiki. I need to do some futher experiments on this... for example if you go to "/xwiki/bin/admin/XWiki/XWikiPreferences?editor=globaladmin&section=Rights" and select the "Global" rather than "Local" option-menu choice -- what happens if you explicitly block any "Global" view access? Would that prevent other wikis on other virtual-hosts from being able to see the document-name-space of the private wiki? Finally, IMHO, in choosing a link from a different wiki in a virtualized environment, it lacks abstraction to have the actual name of the database exposed in the wiki-data. For example if you select a document from a different v-host, it doesn't use the abstraction of the v-host name; rather, the database name is used directly in the wiki-file: "[[iouoiu>>main_xe:Sandbox.renameddoc]]" For commentary relevant to the 2.0 wysiwyg's link-wizard, please see section "(2)" from the message "1.8M2: suggest public vs private v-hosting option to prevent access to other wikis" :: from: Niels Mayer <nielsmayer(a)gmail.com In numerous places in the XE1.8m2 interface, the user is exposed to more > information than is necessary, when virtualhosting ( > http://platform.xwiki.org/xwiki/bin/view/AdminGuide/Virtualization ) is > enabled. > The current virtualhosting implementation seems to assume a shared farm of > wikis where one may want to expose other wikis in the farm. However, one > may also want to use virtualhosting in implementations where there is no > sharing between virtual hosts. > So for example, we have: > (1) the column 'Wiki' in Main.SpaceIndex ( e.g. > http://nielsmayer.com/xwiki/bin/view/Main/SpaceIndex?space=Main ) as well > as Main.WebSearch (e.g. > http://nielsmayer.com/xwiki/bin/view/Main/WebSearch?text=fedora&x=0&… ) > -- shows "host_xe_nielsmayer_dot_com" but it doesn't really need to. > (should be optional). > (2) in the wysiwyg editor's "link editor" ... there's an option-menu > "Choose a wiki: " that > exposes the names of all the wikis, and all their database names. (should > be optional: if "standalone" default to current wiki). > For these, and potentially other cases, I think this behavior should be > optional, not default. Most virtual wiki setups would not want their wikis > to "see" each other, IMHO. This includes a fairly common scenario -- the > private/public wiki setup -- people inserting links via wysiwyg in the > public wiki shouldn't see all the link-names and spaces in the private wiki. > Likewise, the notion of global and local users having potential access to > the wiki should be based on whether the virtual-wiki setup is "shared" or > "standalone." > Finally, exposing the database name of the virtual-wiki (to all search > engines as well) is a small, but unecessary security risk. In #2, for > example, the link editor allows people to see the database names of *all* > the virtual hosts. Also, if one ends up choosing unsightly but descriptive > names like host_xe_nielsmayer_dot_com, users shouldn't need to see it. Niels http://nielsmayer.com