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

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).