<[email protected]> wrote:
I should add that we haven't tested the WYSIWYG in multi-wiki environment so the link feature might have some issues there. It's strange that from your link dialog image it seems that the multi-wiki environment is detected, because the "Choose a wiki" list box is hidden in XE, but the following requests fail.
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§ion=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 <[email protected]>
to: XWiki Developers <[email protected]> date: Sun, Feb 8, 2009 at 10:43 AM subject: 1.8M2: suggest public vs private v-hosting option to prevent access to other wikis
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&y=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