New subject: [xwiki-users] Workspace manager free default pages set + "new idea"

28 Jan 2012

Hi Eduard,

Thanks for explnation. I'm very happy to issue a "new idea", but idea itself
is a bit wider and deeper, then described below. I would like to point out some reasons
and effects to be more clear before "jiraing" it :-)

"Security leak" XE/XEM Usecase

XE/XEM + Workspace Manager. One main Wiki and let's say, hundreds of workspaces. To be
more real we'd add Wiki Manager and tens of virtual wikis running on the same engine
(something like XWiki.com running)

As my humble experience shows, nearly never in natural way XWiki would have only one User
with Admin Rights on the Wiki level.
It's human to be all the time in a hurry and meanwhile XWiki becomes messy inside.
It's not the big problem yet. :-)

As an Admin User on wiki level, I can easily gain programming rights. For now, it's
completely uncontrolled and will run unnoticed.

So, let's imagine that all stars in solar system lined up in a bad way and one Admin
became an AngryAdmin with a revenge as a primary goal of life. Let's make it even
worth: AngryAdmin knows XWiki quite good and scripting for him is an open book. To make it
more real: AngryAdmin doesn't have root access to the server. :-)

At this stage he has all necessary knowledge and access rights to ruin ALL WIKIs onboard.
I didn't dig much in it, but if Workspace Manager has appropriate tools, then it's
possible: one short script and it's over :-)

I didn't met such occasions before, but heard a lot of similar usecases (not with
XWiki :-)

Thus, I NEVER run production on MAIN wiki!

It looks dangerous for me. I'd better be paranoic admin rather embarrased admin. If
somebody will become an "angry-beaver-admin", he would be able to ruin only one
space (now he has a front-end tool for this :-)) or more, but only inside one project and
all running wikis will stay alive. Such workflow keeps my paranoia quiet :-)

SO, at last "new idea":  escape MAIN WIKI from production completely. 

As only global users has programming rights, it looks very logic to leave Main Wiki to
"Core and instances" management and keep it safe from local admins. When U have
a lot of users it sounds reasonable for me.

Let's return to our Case 1-3 described below. The most flexible solution looks as
following:

                             |  virtual wiki 1 -> workspaces
                             |  virtual wiki 2 -> workspaces -> workspaces
(probably)
Main Wiki              |   ..................................................
                             |  virtual wiki N - "Solo" - No Workspace Manager
onboard
(administration)         (production)

Such a way we can run everything simultaneously on the same server. No need to run a lot
of instances. 
If someone want's programming rights, he could be isolated locally and won't
affect other wikis. Looks safe for me.

Bad news:
- Nobody, besides MySQL users would be happy, XEM is MySQL dependent still :-( 

So, before I'd "jira" an idea, I'd like to know community opinion to
keep it comprehensive. 

Hope, it would be nice idea for 4.0 roadmap to think over :-)

Best Regards,

Dmitry

28 января 2012, 00:53 от Eduard Moraru &lt;enygma2002(a)gmail.com&gt;om>:

Hello again,

Please see below...

On Fri, Jan 27, 2012 at 3:17 PM, Haru Mamburu &lt;haru_mamburu(a)mail.ru&gt; wrote:
Thanks a lot for clarification.

It makes sence now from explained point of view, but I still can't get WHY as global
user on NON-workspace wiki I should see Workspace Manager menus?

As I tried to explain in my previous mail, the idea is that you are a global user, coming
from a global context (the main wiki). In that global context, you have the Workspace
application installed and available for you to use. This means that, the Workspace
 application offers you the possibility to create a new workspace, jump to the main wiki
or view existing workspaces trough the top-menu.

From the Workspace application's point of view, it is only natural to allow you to
perform these actions, regardless of your current location (that means even if you are
viewing a non-workspace subwiki). As long as the Workspace application is installed, it
will perform as designed :)

Anyhow I can't use Workspace Manager INSIDE virtual Wiki. It makes sence if you would
extend Workspace manager and make it completely independent on each and every virtual
wiki.

So, the main reason why: it's just useles inside virtual wiki (for now)

Again, the extra menus are not about what you can do on the current wiki, but they are
about what you can do on the whole XWiki, since this is a feature that spans cross wikis
and is not restricted to an individual wiki (even if it is installed on the main wiki).

For me, e.g., ideal workflow looks like:

Case 1. XEM -> virtual wiki isolated, no Workspace Manager on board

This is perfectly doable right now. If you think about the reasons for which you are
creating a regular subwiki and not a workspace, you`ll notice that the main one is that
you want local users. But since local users do not see any extra menus, you are good to
go. Only you, as a global user (or admin) will see those menus, but that is just because
the main wiki is offering you this possibility (since you are its member).

Case 2. XEM -> virtual wiki isolated, WITH Workspace Manager on board. Each virtual
wiki in this case will be able to produce it's own workspaces isolated from each other
(like independent projects on the same server). Only Local Users can take part in
workspace management.

As you might already know, XWiki currently supports only *one level* of virtualisation and
only one main wiki. You can not currently create a subwiki within a subwiki, not even with
the WikiManager application. This means that you can not do this with Workspaces either.

If you wish to obtain this scenario, you will have to set up multiple instances of XWiki.

Having a subwiki within another subwiki might be an interesting new feature for the
WikiManager application (and for Workspaces too). Please feel free to add a new feature
request on jira.xwiki.org for the WikiManager component.

Case 3. XEM -> virtual wiki isolated + Workspace manager on board. Same as Case 2, but
Local Users can log once in any virtual/workspace wiki they allowed AND via this login
have access to each and every wiki they registered/invited.

If I understand correctly, this usecase would imply that local users (created in regular
subwikis or, specifically for your case, in subwikis of subwikis) have a mechanism that
allows them to escape from the isolation of the current subwiki of which they are part of
and gain access to other subwikis or workspaces.

Maybe you could do this by promoting the local user as a global user, optionally putting
him in a special group to better manage rights. This way he/she can create/join workspaces
and join other wikis.

For current purposes I would prefer Case 1 behaviour. Soon I'd like to use Case 2 
then 3 scenario, but for now - no way :-(

Hope it would be useful for futher development.

Yes, as I said, having subwikis within subwikis is a good idea that might actually be not
so hard to implement (as far as Thomas tells me).

 Hope this helped.

Thanks,
Eduard 

Kind Regards,

Dmitry

27 января 2012, 16:48 от Eduard Moraru &lt;enygma2002(a)gmail.com&gt;om>:

Oh, I see now.

The way it works now when visiting a normal subwiki (not a workspace) is that:

1) If you are a global user (user of the main wiki), the menus will be displayed to you
(and you will be thus exposed to the global context of which you are part of).

2) If you are a local user (user of a subwiki that is part of a wiki *farm*), you don`t
see the menus any more and are isolated inside the wiki (and not exposed to the global
context).

So, as a conclusion, the menus appear to you based on your user type and not on the type
of wiki you are currently viewing.

Does that make sense now? Does this fit your usecase? If not, can you please elaborate on
the reason why you would like global users not to be able to see the global context when
viewing a regular subwiki?

Thanks,
 Eduard

On Fri, Jan 27, 2012 at 1:32 PM, Haru Mamburu &lt;haru_mamburu(a)mail.ru&gt; wrote:
 Thank you Eduard,

Sorry, probably I wasn't clear in my questions...

- I want to use WORKSPACE Manager on MAIN Wiki and manage them as designed.
- BUT, the same time I want to use WIKI Manager to have completely independent from main
wiki and other workspaces virtual wikis.

So, I set up XEM, installed Workspace manager to play around AND with Wiki Manager created
virtual Wiki.
Now I completely stuck how to get rid of all Workspace Manager links in wiki farm (!) (not
workspaces). I would prefer to keep running Workspace Manager on main Wiki AND Wiki farm
simultaneously, if possible.

Is there any simple solution?

The only thing I suppose should work is to take *.vm files from XE and attach them to the
skin file. Looks wierd and unpredictable for me :-(

Kind Regards,

Dmitry

27 января 2012, 14:26 от Eduard Moraru &lt;enygma2002(a)gmail.com&gt;om>:

Hi Dmitry,

Starting with 3.3, XEM has moved the main usecase for subwikis from farm to workspaces.
This means that, additionally to the WikiManager application [1], now XEM also contains
the Workspace Application [2].

The encouraged way of for creating a wiki farm right now (if that is really what you need)
is to get XE, install WikiManager [1] and create your farm.

If you *insist* on using XEM for creating a wiki farm, all you have to do is delete the
WorkspaceManager space, thus removing the Workspaces application and disabling the extra
menus that were getting in your way. Additionally, you should also remove the
xwiki-platform-workspace-api-<version>.jar file from the /webapps/xwiki/WEB-INF/lib/
folder, since you don`t want to use it anymore and you have removed the UI.

However, if your plan is to have global users that work on different subwikis (like an
intranet with departments mapped to subwikis or a place where you work on projects mapped
to subwikis, etc.), you might reconsider using Workspaces.

In any case, I hope this solves your problem.

Thanks,
Eduard

-----------------
References:
[1] http://extensions.xwiki.org/xwiki/bin/view/Extension/Wiki+Manager+Applicati…
 [2] http://extensions.xwiki.org/xwiki/bin/view/Extension/Workspace+Application

On Fri, Jan 27, 2012 at 11:57 AM, Haru Mamburu &lt;haru_mamburu(a)mail.ru&gt; wrote:
Ooops, wrong solution. The problem is still active: is there a right way to get rid of
Workspace Manager's links in virtual wikis in 3.4?

27 января 2012, 13:46 от Haru Mamburu &lt;haru_mamburu(a)mail.ru&gt;ru>:
...
  Hi All,

 By accident I found a soluion. For me it looks a bit wierd.

 If you set in xwiki.cfg  xwiki.virtual.usepath to 0, then all menus become Workspace
Manager links free.

 For now, if I want to use usepath and don't want to use Workspace Manager, there is
no an "one click solution" :-(

 Is it a bug or it's a feature? Should I report it?

 Kind regards,

 Dmitry

 27 января 2012, 01:34 от Haru Mamburu &lt;haru_mamburu(a)mail.ru&gt;ru>:
 > Hi. all!
 >
 > XEM 3.4. Main Wiki works fine.
 >
 > I want to set up virtual wiki without Workspace Manager application inside and
it's links in menu, because as far as I inderstood it is useless in virtual wikis.
 >
 > What is right way to get rid of Workspace Manager and it's links in top menu in
virtual wiki?
 >
 > Kind regards,
 >
 > Dmitry _______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

_______________________________________________
users mailing list
users(a)xwiki.org
http://lists.xwiki.org/mailman/listinfo/users

Re: [xwiki-users] Workspace manager free default pages set + "new idea"