Hello Fabio & friends,
Previously I had emailed a possible work around to make sure that
XWiki.Guest user does not have access to the list of Spaces in a completely
private wiki instance. In the meantime, I was working on a possible
resolution to the issue of Tags being publicly accessible to XWiki.Guest in
a private wiki.
Submitting my code change for your kind consideration:
I modified the file TagsResource.java in package
org.xwiki.rest.resources.tags.
I replaced the method :
private List<String> getAllTags() throws QueryException
{
String query =
"select distinct elements(prop.list) from BaseObject as obj, "
+ "DBStringListProperty as prop where
obj.className='XWiki.TagClass' "
+ "and obj.id=prop.id.id and prop.id.name='tags'";
List<String> tags = queryManager.createQuery(query,
Query.HQL).execute();
Collections.sort(tags, String.CASE_INSENSITIVE_ORDER);
return tags;
}
With the following code:
private List<String> getAllTags() throws QueryException
{
List<String> tags=null;
if(!Utils.getXWikiUser(componentManager).equalsIgnoreCase("XWiki.Guest")){
String query =
"select distinct elements(prop.list) from BaseObject as obj, "
+ "DBStringListProperty as prop where
obj.className='XWiki.TagClass' "
+ "and obj.id=prop.id.id and prop.id.name='tags'";
tags = queryManager.createQuery(query, Query.HQL).execute();
Collections.sort(tags, String.CASE_INSENSITIVE_ORDER);
}
return tags;
}
}
I am unable to throw a "authentication required" in the browser.
However, I am able to block the anonymous/Xwiki.Guest user from accessing
the list of tags :)
Next, I need to investigate if the anomaly exists with Classes, Objects,
etc.
Thank you folks...
------------------------------
Message: 3
Date: Wed, 27 Jan 2010 17:57:02 +0530
From: "Dilipkumar Jadhav" <jadhav.dilipkumar(a)gmail.com>
Subject: Re: [xwiki-users] REST services access to spaces & tags
To: <users(a)xwiki.org>
Message-ID: <4b60313f.5644f10a.7b9c.4011(a)mx.google.com>
Content-Type: text/plain; charset="us-ascii"
Hello friends,
I had enquired on the mailing list about the access to Spaces & Tags on a
strictly private wiki.
I believe I might have a resolution:
Possible Resolution:
1. I checked out the XWiki Platform - Core -REST module for XWiki 2.1.1.
2. As per the original issue, the Pages were not accessible but Spaces were
accessible in a private wiki even without authentication.
Hence, I found the two class files & compared them, viz.
a. SpacesResource.java in package org.xwiki.rest.resources.spaces
b. PagesResource.java in package org.xwiki.rest.resources.pages
3. In SpacesResource.java replaced the following code:
if (Utils.getXWikiApi(componentManager).exists(homeId)) {
home =
Utils.getXWikiApi(componentManager).getDocument(homeId);
}
spaces.getSpaces().add(
DomainObjectFactory.createSpace(objectFactory,
uriInfo.getBaseUri(), wikiName, spaceName, home));
With the following code:
if (Utils.getXWikiApi(componentManager).exists(homeId)) {
home =
Utils.getXWikiApi(componentManager).getDocument(homeId);
if (home != null) {
spaces.getSpaces().add(
DomainObjectFactory.createSpace(objectFactory,
uriInfo.getBaseUri(), wikiName, spaceName, home));
4. Compiled the module jar & deployed it on the XWiki instance.
5. Now, the spaces show up only when the user has been authenticated through
the browser. When there is no authentication, all that is displayed is an
empty </spaces> tag. So things do look partly the way I wanted them to work.
I have following two questions at this point of time:
1. Is this the right way to do it. Did I end up breaking something else that
was working?
2. If this is the correct resolution, how could I add a Status.UNAUTHORIZED
when there is no authentication?
Any help will be greatly appreciated. Thank you for your time &
consideration folks.
2. REST services access to spaces & tags (Dilipkumar Jadhav)
Message: 2
Date: Mon, 25 Jan 2010 17:45:27 +0530
From: "Dilipkumar Jadhav" <jadhav.dilipkumar(a)gmail.com>
Subject: [xwiki-users] REST services access to spaces & tags
To: <users(a)xwiki.org>
Message-ID: <4b5d8b69.0404c00a.65db.ffffafa7(a)mx.google.com>
Content-Type: text/plain; charset="us-ascii"
Hello friends,
I am facing some unexpected behavior with RESTful services in private wiki
instance:
Issue: Spaces, Tags entities can be accessed publicly through REST URL,
eventhough XWiki is run in private wiki mode.
Description: One of the XWiki 2.1.1 instance is setup in a private wiki
mode. Guests are not allowed to register or view any page on this instance.
I am also making use of authenticated services (RESTful services & XMLRPC
services) for connecting 3rd party applications to this xwiki instance.
However, when I access REST URLs for spaces, tags, etc there is no
authentication check from XWiki. This data is publicly available. When I
access a page URL, I am blocked off for authentication.
Couldn't find a JIRA for this one. Could we consider this as an
non-consistent behavior in terms of xwiki REST authentication where one
resource is blocked while others are not.
Has anyone else faced this before or has a work-around to this issue.
Thank you for your time & consideration friends.
Environment:
XWiki : 2.1.1 stable
Tomcat: 6.0.20
MySql: 5.0.45 community
JDK: 1.5 (Apparently, REST services do not work for me through JDK 1.6. This
could be just me facing this issue though J)
------------------------------
Message: 4
Date: Wed, 27 Jan 2010 14:44:30 +0100
From: Fabio Mancinelli <fabio.mancinelli(a)xwiki.com>
Subject: Re: [xwiki-users] REST services access to spaces & tags
To: XWiki Users <users(a)xwiki.org>
Message-ID: <82E246C5-ED52-405B-86D0-6B50BBB50DBA(a)xwiki.com>
Content-Type: text/plain; charset=us-ascii
On Jan 27, 2010, at 1:27 PM, Dilipkumar Jadhav wrote:
Hello friends,
I had enquired on the mailing list about the access to Spaces & Tags on a
strictly private wiki.
I believe I might have a resolution:
...
Hi Dilipkumar,
thanks for your mail. It seems that there is actually a problem or, at
least, an inconsistency.
Though, I need some time to investigate the problem and check your solution
(thanks for prividing a quick patch!)
I'll come back to you as soon as I'm done.
Regards,
Fabio