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