My POV is that XWiki should use JAAS. Then we'll automatically get
lots of benefits including SSO. We could even use JGuard for this if
it helps (FYI, JGuard is a project of our OSSGTP group in Paris).
Thanks
-Vincent
On Apr 13, 2007, at 1:20 PM, Sergiu Dumitriu wrote:
The comments below are just how I see things, I could
be wrong.
On 4/13/07, Thomas Krämer <tk(a)ontopica.de> wrote:
Hello xwiki developpers
Imagine you had to powerful applications.
First xwiki, then discourse engine for deliberative decision making.
Lets call the latter 'dito'.
Imagine how nice it would be,
1: if these two applications could use the same authentication, and if
2: signing into one aplication would sign you into the second, too.
3: registering a new account in dito would add a new user to xwiki
with
the appropriate rights (edit) without admin interaction (explicitly
setting rights) needed
It would be very nice.
@1: Done!
Fortunately, as far as *authentication* is concerned, xwiki makes a
geeks life easier, as it provides a XWikiAuthService interface.
Which I implemented for my needs and which works fine.
Which one uses the other? As far as I can guess, you made XWiki
communicate with dito's database.
@2: Hm, solve 3 first
Authentication creates some cookies holding authentication
information.
1. You can create these cookies when authenticating in dito and set
them as cookies that have to be sent to xwiki. Then the XWiki
authentication mechanism will deal with them.
2. You can create other cookies when authenticating in xwiki that
would later be used by dito.
@3: Stuck!
Unfortunately, as far as *authorisation* is concerned, I did not
yet get
the point.
My approach is to make an xml-rpc, that logs into the wiki (with a
user
that i added manually and that has admin rights) and calls the
XWiki.createUser() method.
This approach seems to be OK. But you can also use a REST approach,
meaning that you learn how does the registration form work, then
create a fake request (GET or POST, which one is easier). If
registration is not public, then you also need to send some
authentication tokens (cookies).
In order to achieve that, i extended the ConfluenceRpcHandler and
added
a method createUserFromExternal
Suddenly, I get an error in Xwiki, approx. line 2570(i.e. methods
system.out.println("xwiki create user :
!context.getUtil().match"+xwikiname);returns -4 :)
try {
if (!context
.getUtil()
.match(
this.Param(
"xwiki.validusername", "/^[a-zA-Z0-9_]+$/"),
xwikiname))
{
return -4;
}
}
As i am calling from external, the context object (and the request, it
is carrying) are not as complete as they are, when i register via the
xwiki web page.
My questions are:
- is it a good idea to do xwiki user registration automatically and
from
external *that* way? do you know alternatives?
Depending on what is the main application, you could even forget
about the XWiki users. You can implement a Rights&Authentication
mechanism that uses only external data. But this would take a bit
longer.
Your approach is OK, too. It's wrong that it does not work, but the
XMLRPC API is still experimental, and mostly unmaintained due to
lack of human resources.
- is there an implementation of the mehtod:
/**
* {@inheritDoc}
* @see ConfluenceRpcInterface#addUser(String, java.util.Map,
String)
*/
public void addUser(String token, Map user, String password)
throws
XWikiException {
throw new XWikiException(XWikiException.MODULE_XWIKI_XMLRPC,
XWikiException.ERROR_XWIKI_NOT_IMPLEMENTED, "Not
implemented");
}
?
- If you integrate xwiki into other environments or vice versa,
what is
the best practice to wire the two different registration and login
processes of both, xwiki and some_app ?
The best practice is to implement a SSO mechanism in both
applications. Currently XWiki lacks something like this, but it is
planned. The next best mechanism is to make one of the applications
use the data from the other, since maintaining duplicate
information is hard, and I don't mean just creating data in two
places, but the different updates that can later occur.
Of course, i searched the archives, but no solution for this so far...
Any hints?
Best regards
Thomas K.
Sergiu
--
http://purl.org/net/sergiu
--
You receive this message as a subscriber of the xwiki-
dev(a)objectweb.org mailing list.
To unsubscribe: mailto:xwiki-dev-unsubscribe@objectweb.org
For general help: mailto:sympa@objectweb.org?subject=help
ObjectWeb mailing lists service home page:
http://www.objectweb.org/
wws