May 2008 - xwiki-devs@xwiki.org

[xwiki-devs] [VOTE] Fabio Mancinelli as core committer
by Vincent Massol 12 Jun '08

12 Jun '08

Hi, I'd like to propose Fabio as a core committer. Fabio has been mostly participating in the rewrite of the XMLRPC support and I think it's important that he has access to maintain and improve it. Fabio's patches are very good too. In addition I believe Fabio is professional enough to not commit things he's not sure about if he's modifying other parts of the core and ask for core review instead. Last, if this make Fabio contributes to other parts in the core, then that's great for the project! Here's my +1 Thanks -Vincent

7 7

Re: [xwiki-devs] ntlm with xwiki [END]
by Colin Tay 11 Jun '08

11 Jun '08

Hello, I have managed to authenticate users with the Active directory through LDAP. However, all the users i login were shown the error message "You are not allowed to view this document or perform this action." when i am at http://localhost:8080/xwiki/bin/view/Main/WebHome. I pressume the users records are not in the Xwiki database. Where and how do i create these records when the user first logon onto xwiki? Regards, ----- Original Message ---- From: arnaud <adlz(a)netcourrier.com> To: devs(a)xwiki.org Sent: Thursday, 15 November 2007 2:01:06 Subject: Re: [xwiki-devs] ntlm with xwiki [END] hello FYI it works !! just had to use the createUserFromLdap from Ldap plugin class now user are recognized by xwiki and authenticated by ntlm! At last! ----Message d'origine---- >Date: Mon, 12 Nov 2007 22:20:27 +0100 (CET) >De: "Jerome Velociter" <jerome(a)xwiki.com> >A: "XWiki Developers" <devs(a)xwiki.org> >Sujet: Re: [xwiki-devs] ntlm with xwiki > >Hi Arnaud, > >As far as your problem, I can't really help you much as I've never >experimented custom auth. I don't know how LDAP binds the users to actual >XWiki users, but I suppose for this to work, you should at some point feed >XWikiUsers documents/objects with data from LDAP. (since LDAPAuthImpl is >only auth, maybe there is something else needed). >Maybe you can ask this on the users list, as it is both more of a user >issue, and you could get insights from those who actually use LDAP >auth/user management. > >Good luck with this, >Jérôme. > >> >> hi again >> >> very sorry to disturbing you once again >> >> i saw that i can get request from wikicontext >> so in my own auth class i can get my user >> no longer need a servlet to send user to the login form >> great everything is fine BUT >> >> first: i still have "you are not allowed to view this document ...." when >> the user log in >> >> >> second : i can't log out >> >> problem look like xwiki don't know my user >> (in my AuthImpl i did all that it's found in LDAPAuthImpl...) >> >> sorry again >> (BTW if it's not the right place to ask this kind of questions, tell me, >> no problem...) >> >> >> >> >> >> >> >> >> >> >> >> ----Message d'origine---- >>>Date: Sat, 10 Nov 2007 23:19:23 +0100 (CET) >>>De: "Jerome Velociter" <jerome(a)xwiki.com> >>>A: "XWiki Developers" <devs(a)xwiki.org> >>>Copie à: devs(a)xwiki.org >>>Sujet: Re: [xwiki-devs] ntlm with xwiki >>> >>>Hello, >>>> >>>> First of all Sorry for creating a new topic >>>> >>>> thanks for your anwser Jerome. >>>> >>>> but Actually i have seen this feature >>>> >>>> i added jcifs and it works well >>>> an other hand i have tested impletentetion for ldap its works too >>>> >>>> but i want a transparent authentication >>>> so now the problem is : >>>> >>>> i would like to not have form login >>>> i saw in code that we can define our login page with this property in >>>> xwiki.cfg : >>>> xwiki.authentication.loginpage (if null default is >>>> /bin/login/XWiki/XWikiLogin) >>>> >>>> i've changed this property but no changes when template call >>>> >>>> $xwiki.getURL("XWiki.XWikiLogin", "login", "xredirect=$logredir")) >>>> >>>> i still got the same url : bin/login/XWiki/XWikiLogin? >>> >>>Actually, it's the expected behavior : the call asks for the URL of the >>>XWiki.XWikiLogin document, under the login action and with a xredirect >>>query string parameter. If you changed your authentication login page to >>>XWiki.MyCustomLogin in the conf, the calls to login URL should ask for >>>that document IMO. Also, you may have to modidy a bit the skin if you >>> want >>>the users to be redirected to the proper login page any case. If you are >>>using albatross skin, you can look over global.vm and login.vm, there is >>>also the header.vm file in the webapp/templates folder that calls for the >>>login URL. >>> >>>Hope it's clear enough, as I'm not sure what you exactly want to do (In >>>particuliar, I don't understand why you wany to post username to >>>loginsubmit action, since you use third-party authentication). >>> >>>Tell us how it goes. >>> >>>Regards, >>>Jerome. >>> >>>> >>>> >>>> the purpose of that is log-in link goes to my servlet , then i do ntlm >>>> authentication (it already works), then i post user name to >>>> /xwiki/bin/loginsubmit/XWiki/XWikiLogin >>>> >>>> in the same time i do my own version of authentification (get user info >>>> (name mail,etc...) from another ldap without test of password cos >>>> already >>>> done with ntlm) >>>> >>>> >>>> So! how can i redirect log-in page ? thanks a lot >>>> >>>> ------------------------------------------------------------ >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> Hi, >>>> >>>> You can implement your own version of the >>>> com.xpn.xwiki.user.api.XWikiAuthService interface. >>>> >>>> There's already a LDAP impl existing (different from the XWiki default >>>> one), so you can look over that too as an example. >>>> >>>> Then, you must precise in the xwiki.cfg configuration file that you >>>> want >>>> to use your own class, with something like >>>> >>>> xwiki.authentication.authclass = >>>> com.mycompany.mypackage.MyXWikiAuthImpl >>>> >>>> Regards, >>>> Jerome. >>>> >>>> _______________________________________________ >>>> devs mailing list >>>> devs(a)xwiki.org >>>> http://lists.xwiki.org/mailman/listinfo/devs >>>> >>> >>> >>>_______________________________________________ >>>devs mailing list >>>devs(a)xwiki.org >>>http://lists.xwiki.org/mailman/listinfo/devs >>> >> >> _______________________________________________ >> devs mailing list >> devs(a)xwiki.org >> http://lists.xwiki.org/mailman/listinfo/devs >> > > >_______________________________________________ >devs mailing list >devs(a)xwiki.org >http://lists.xwiki.org/mailman/listinfo/devs > _______________________________________________ devs mailing list devs(a)xwiki.org http://lists.xwiki.org/mailman/listinfo/devs __________________________________ Yahoo! Movies - Search movie info and celeb profiles and photos. http://sg.movies.yahoo.com/

2 1

[xwiki-devs] [Vote] Release XEM 1.2 final
by Thomas Mortagne 10 Jun '08

10 Jun '08

Hi devs, As XE 1.4 final is now released I would like to follow with XEM 1.2 final. The main "pure" XEM new feature is the wiki name ajax based validation, it also fix some bugs. See http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesXEM12 for details. Here is my +1 -- Thomas Mortagne

3 9

[xwiki-devs] XWikiLDAPAuthService
by Fabien 05 Jun '08

05 Jun '08

Hi again, During my search into LDAP code, I found that the xwiki.cfg check_level was removed in the new XWikiLDAPAuthService that deprecate the LDAPAuthService. It is a pity because for my pb I only need to check if the LDAP Bind is ok or not to authenticate my user, and this works perfectly (except the allocated XwikiGroup) with the old LDAP authentication mechanism. Is it possible to re-add the check_level param in the current XwikiLDAPAuthService ? Fabien

2 3

[xwiki-devs] Refactoring Administration and Preferences
by Sergiu Dumitriu 04 Jun '08

04 Jun '08

Hi devs, This is somewhat in response to the discussion about the new Administration page design. Behind the scenes, there was a discussion about where should the Import page put the uploaded xar, in XWiki.Import (as it is done now), or in XWiki.XWikiPreferences. Both sides agreed that the administration should automatically find and use administration pages, but didn't agree on what "use" means. So, how should things work? A. The main administration page contains links to other pages B. The main administration page includes other administration sheets Option A means that each administration topic uses its own page to store configuration, which somehow breaks the current configuration mechanism, where all (global) settings go into the XWiki.XWikiPreferences page. Option B means that each administration document is used only as a sheet, so all objects will be in XWiki.XWikiPreferences. If we choose B, then the best thing to do is to attach imported xars to the XWikiPreferences page, instead of Import. Doing otherwise will either be very hard or would break the convention. So, the main question is: Do we keep all settings in the same document? Or do we allow each application/component to have its configuration in its own document? I think it would be better to have all the configuration in one place, instead of spreading it all over the wiki. And since we're touching the configuration part, I think we should completely rewrite this part, as the current system is sooo bad (I mean the XWiki#get[User/Web/XWiki]Preference[AsSomething] methods and the giant XWikiPreferences class). This was supposed to be a Configuration proposal that I was thinking about, but didn't have the time to write until now. So here it is: Requirements: 1. We should allow an application/component to be configured at the farm, wiki, space, user and document level (the specificity can be configured for each setting), with static values in the component's xml configuration and default values in the java class file or in the template/wiki document using the configuration (depending on whether there is a component/java/template part). 2. An application should be able to define its own customization xclasses, the same class being usable for all levels of customization (now, some settings go both in XWikiUsers class and XWikiPreferences class). In fact, XWikiPreferences should disappear completely. 3. Global (farm) settings should go in [mainwiki]:Admin/GlobalPreferences, wiki settings should go in Admin/WikiPreferences, space settings should go in <Space>/SpacePreferences, user settings should go in the user profile. The current locations are inappropriate (WebPreferences??). [I'm not sure if Preferences is a good name, as the list of blog categories is not exactly "preferences", but more like "settings"] 4. The settings pages include an administration sheet, which later lists all customization pages in the wiki that are customizable at that level (for the moment, using an explicit search, later using Interface Extensions). 5. The configuration should be accessible using a simple API, which should find the right settings, internally taking care of all the details: consider the lowest level for that setting (some settings are valid only at the wiki level, or even global, so don't search or allow settings at a lower level), security (some settings should only be taken into consideration if the author is trusted), in-wiki and in-file settings. This means that the application should call one method, and not have a complicated code combining getUserPreference, getWebPreference, getXWikiPreference and Param. 6. All this should be done without changing the data model (meaning that we use the classic xclasses/xobjects for this). How things work: An application lists one or several wiki documents in its application description as customization classes. Administration sheets (also from the application) are then autoincluded in the global, wiki or space Administration page, and in the user settings page. Such a sheet would check if the class allows customization at the current level, and if not, warns about this. If there is no instance of the target class, it provides a link for creating one (doing it automatically is another option, but I don't think it is a good idea, as this pollutes the wiki with unused objects). The sheets should follow a common guideline, for consistency. All options should be documented in the sheet. The application code then calls the settings component API to check the settings that apply for the current document/user. Of course, all this with lots of caching for good performance (this is not the case in the current core, as a lot of time is spent cloning XWikiPreferences in HibernateCacheStore). The hard part is deciding how to configure these classes and sheets. Since we shouldn't use different Property types, we can't add a customizationLevel metaproperty. A feasible solution would be to require all properties in the same class to have the same level of configuration, and either specify in the application description, or use a tag for that. The best would be to have a document property, but the current data model does not have that. Proposed API variant 1: /* Gets the current setting for an application, from the specified class. */ String getSetting(applicationName, className, settingName); /* Same as above, when the application has only one settings class defined. */ String getSetting(applicationName, settingName); /* If the current document is known to belong to a certain application, get a setting for that application */ String getSetting(settingName); /* Stops at a specified level, instead of the default one. */ String getSettingForLevel(applicationName, className, settingName, maxLevel); /* Returns the setting at a specified level, with no inheritance. */ String getSettingAtLevel(applicationName, className, settingName, exactLevel); Proposed API variant 2: /* Search for the setting name in the attached objects. */ String getSetting(settingName); /* Gets the current setting, from the specified class. */ String getSetting(settingName, className); /* Stops at a specified level, instead of the default one. */ String getSettingForLevel(settingName, className, maxLevel); /* Returns the setting at a specified level, with no inheritance. */ String getSettingAtLevel(settingName, className, exactLevel); - I don't know if we need methods returning other types, like int or double, since we can use velocity tools for converting the returned string - I don't know if we should have the applicationName in the parameter list, or just the className; my take is that specifying the application name is a bit more semantical and less technical - maxLevel should be an enum, but we need a custom introspector for this to work - maxLevel assumes a fixed order of levels, which is an obvious one, except for the User level. Where should that be in this order? Is the user preference the most important one? So, WDYT? -- Sergiu Dumitriu http://purl.org/net/sergiu/

3 5

[xwiki-devs] [proposal] Change the maximum line width in the codestyle to 128 characters
by Sergiu Dumitriu 04 Jun '08

04 Jun '08

Hi devs, Vincent said that he wanted to propose increasing the maximum line width for a while, but didn't get to do it yet. And since I want the same thing, I'm writing the proposal. So, the idea is to increase the line width to 128 (or 120? I like 128 better), since: - nice code uses descriptive variable/method names, which tend to be quite long, so many method calls span 2 or more lines - we're past the stage where developers have small displays that can only display 80 (or 100) characters at a time - right now the eclipse settings are at 98 chars, which is quite a silly number, and changing to only 100 is not worth the effort, so while we're increasing it, we can use a larger value Migration plan: - first, change the xwiki-verification-tools (next Tuesday) - we don't want to do a massive update, since it will probably create conflicts with the local changes for each developer, and break existing patches - whenever someone changes a file, he should first do a cleanup and commit the file without code changes, then a second commit with the actual behavior fix - never mix cosmetic changes with actual code affecting the behavior, as it will be hard to review that change - the copyright notice doesn't need to be updated So, everybody agrees? Do we use 120 or 128? -- Sergiu Dumitriu http://purl.org/net/sergiu/

4 5

[xwiki-devs] "List of Groups" property error
by shivshan 03 Jun '08

03 Jun '08

Hi If i try to add a property of type "List of Groups", i get the followng error. Is this a known issue? XWiki XE 1.4 running on Windows XP. Thanks, Shiva A problem occured while trying to service your request. Please contact the support if this happens again. Detailed information: Error number 0 in 11: Uncaught exception Wrapped Exception: com.xpn.xwiki.objects.meta.GroupsMetaClass com.xpn.xwiki.XWikiException: Error number 0 in 11: Uncaught exception Wrapped Exception: com.xpn.xwiki.objects.meta.GroupsMetaClass at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:230) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:616) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) Wrapped Exception: java.lang.ClassCastException: com.xpn.xwiki.objects.meta.GroupsMetaClass at com.xpn.xwiki.web.PropAddAction.action(PropAddAction.java:56) at com.xpn.xwiki.web.XWikiAction.execute(XWikiAction.java:204) at org.apache.struts.action.RequestProcessor.processActionPerform(RequestProcessor.java:431) at org.apache.struts.action.RequestProcessor.process(RequestProcessor.java:236) at org.apache.struts.action.ActionServlet.process(ActionServlet.java:1196) at org.apache.struts.action.ActionServlet.doPost(ActionServlet.java:432) at javax.servlet.http.HttpServlet.service(HttpServlet.java:616) at javax.servlet.http.HttpServlet.service(HttpServlet.java:689) at org.mortbay.jetty.servlet.ServletHolder.handle(ServletHolder.java:428) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:830) at com.xpn.xwiki.web.SetCharacterEncodingFilter.doFilter(SetCharacterEncodingFilter.java:112) at org.mortbay.jetty.servlet.WebApplicationHandler$CachedChain.doFilter(WebApplicationHandler.java:821) at org.mortbay.jetty.servlet.WebApplicationHandler.dispatch(WebApplicationHandler.java:471) at org.mortbay.jetty.servlet.ServletHandler.handle(ServletHandler.java:568) at org.mortbay.http.HttpContext.handle(HttpContext.java:1565) at org.mortbay.jetty.servlet.WebApplicationContext.handle(WebApplicationContext.java:633) at org.mortbay.http.HttpContext.handle(HttpContext.java:1517) at org.mortbay.http.HttpServer.service(HttpServer.java:954) at org.mortbay.http.HttpConnection.service(HttpConnection.java:816) at org.mortbay.http.HttpConnection.handleNext(HttpConnection.java:983) at org.mortbay.http.HttpConnection.handle(HttpConnection.java:833) at org.mortbay.http.SocketListener.handleConnection(SocketListener.java:244) at org.mortbay.util.ThreadedServer.handle(ThreadedServer.java:357) at org.mortbay.util.ThreadPool$PoolThread.run(ThreadPool.java:534) -- View this message in context: http://www.nabble.com/%22List-of-Groups%22-property-error-tp17574276p175742… Sent from the XWiki- Dev mailing list archive at Nabble.com.

2 3

[xwiki-devs] Openoffice sdk client need openoffice runtime to run
by Wang Ning 03 Jun '08

03 Jun '08

Hi, I want to develop a component to handle office documents in xwiki. As we discussion before, I want to use openoffice api. I set a openoffice develop environment in my pc running ubuntu 8.04, and learn how to use openoffice api. Yes, The oo sdk is powerful to address office documents, MS doc, MS excel... But there's a problem. AFAIK, openoffice api need a openoffice local runtime or a remote server running openoffice. The whole openoffice runtime is 356M, more or less, so we shouldn't contain it in xwiki release. Hense, I think if we want the office importer run in a computer, the computer should have installed openoffice or configurate a remote openoffice server. WDYT? I need some suggestion. Thanks. -- Sincerely, Wang Ning

5 7

[xwiki-devs] XWiki Enterprise 1.4.1 to be released ASAP
by Jean-Vincent Drean 02 Jun '08

02 Jun '08

Hi XWikiers, XWiki Enterprise 1.4 has introduced a regression for group management in farm mode. We strongly suggest to use XWiki Enterprise 1.3.2 if you are upgrading a wiki farm before the 1.4.1 release. XWiki Enterprise 1.4.1 is planned on june 2nd and will be performed by Thomas Mortagne, it will include the following fixes : * XWIKI-2413 : Global groups are not taken into account in a virtual wiki Anything missing in the list ? Thanks, -- Jean-Vincent Drean

6 9

[xwiki-devs] Google AJAX Libraries API
by Fabio Mancinelli 01 Jun '08

01 Jun '08

Hi all, Maybe this can be interesting... http://code.google.com/apis/ajaxlibs/ Cheers, Fabio

5 4