- xwiki-devs@xwiki.org - lists.xwiki.org

by Michael Oliver

Has anyone looked into DB2 pure xml for XWiki? http://www.ibm.com/developerworks/db2/library/techarticle/dm-0707singh/ and http://www.ibm.com/developerworks/edu/dm-dw-dm-0606leung-i.html Points to what I believe is strong support for the XWiki data model. I helped write the DB2 Viper store for the Jakarta Slide project and in that implementation we went from 40 tables to shred objects down to 4, so given XWiki's bent on xml it seems likely there would be similar gains in simplicity. Ollie <http://www.corenttech.com> On Demand Solutions On Demand Michael Oliver Chief Technology Officer Corent Technology <http://maps.yahoo.com/py/maps.py?Pyt=Tmap&addr=3600+W+Florida+Ave&csz=Hemet %2C+CA+92545&country=us> 3600 W Florida Ave #340 Hemet, CA 92545 <mailto:moliver@corenttech.com> moliver(a)corenttech.com <http://www.corenttech.com> http://www.corenttech.com AIM: moliver(a)corenttech.com tel: fax: mobile: Skype ID: <http://www.plaxo.com/click_to_call?src=jj_signature&To=949-547-5700&Email=m oliver(a)corenttech.com> 949-547-5700 7029740341 <http://www.plaxo.com/click_to_call?src=jj_signature&To=949-547-5700&Email=m oliver(a)corenttech.com> 949-547-5700 MikeOliverAZ <https://www.plaxo.com/add_me?u=55837372229&src=client_sig_212_1_banner_join &invite=1> Want to always have my latest info? <http://www.plaxo.com/signature?src=client_sig_212_1_banner_sig> Want a signature like this? View <http://corenttech.ning.com/xn/detail/u_25igigalsj1dt> my page on Corent Technology View my page <http://linkedinspin.ning.com/xn/detail/u_25igigalsj1dt> on CMU SEI LinkedIn SPIN

17 years, 6 months

1
0
0 0

[xwiki-devs] [Proposal] XE 1.4 roadmap + release dates

by Vincent Massol

Hi, I've published the XE 1.4 general roadmap directions on http://www.xwiki.org/xwiki/bin/view/Main/Roadmap In addition here's a proposal for the release dates: * 1.4M1: 28th of March 2008 * 1.4M2: 18th of April 2008 * 1.4RC1: 25th of April 2008 * 1.4RC2: 2nd of May 2008 * 1.5 Final: 6th of May 2008 I'm entering those into JIRA Ok with everyone? Thanks -Vincent

17 years, 6 months

2
2
0 0

[xwiki-devs] Java version?

by Kamna Jain

Can somebody tell me what version of JAVA is being used to develop XWiki? Thanks

17 years, 6 months

2
1
0 0

[xwiki-devs] Building the source for XWiki Enterprise 1.3

by Marco K.

Hi all, I downloaded XWiki Enterprise 1.3 RC1 some weeks ago and brought it to run with MySql 4 and Tomcat 5.0.28. Now, I want to do the same for the new version 1.3, but I want to build this version from source. Is there a way to get the complete source of version 1.3? (For Building - and especially for my understanding) And how can I compare the differences of the source code of two released versions (e.g. XWiki Enterprise 1.2 and 1.3), so that I can review the consequences of changing a release in the future? Thanks a lot and best Regards, Marco P.S. I'm new to this list. Please apologize, if this question is asked before.

17 years, 6 months

3
4
0 0

[xwiki-devs] XWiki and Eclipse debugging

by Thomas Mortagne

Hi committers, I don't know the only one who do that to debug XWiki on Eclipse I'm creating web project mirror of the product web I'm working on (for example XEM) and use "j2ee module dependencies" property to dynamically link xwiki-core and plugins. This way when modifying something in plugin it's automatically built and published without the need to rebuild all XEM to get a complete distribution package with all necessary dependencies included. I think it's pretty similar to what I seen for some of you with IntelliJ IDEA. The "problem" here is that Eclipse automatically add META-INF/MANIFEST.MF file in the first source directory of web project linked projects it can find : in our case it's always src/main/java (at least in core/plugins/components cases). In this case Eclipse does not generate this file at build time like maven do. Considering that we never add META-INF in src/main/java but in src/main/resources for a maven project I always added it to svn:ignore in the past. As I had a chat with Vincent who is not agree with this way to do I'm wondering what you think of that ? -- Thomas Mortagne

17 years, 6 months

1
0
0 0

[xwiki-devs] why hasn't the class deletion been implemented?

by Pascal Voitot

This might seem stupid but what are the limitations in class/object deletion? br Pascal

17 years, 6 months

3
7
0 0

Re: [xwiki-devs] [xwiki-notifications] r8601 - xwiki-platform/xwiki-plugins/trunk/spacemanager/src/main/java xwiki-platform/xwiki-plugins/trunk/swizzle/src/main/java xwiki-products/xwiki-enterprise-manager/trunk/distribution-test/selenium-tests xwiki-products/xwiki-enterprise-manager/trunk/distribution-test/xmlrpc-tests

by Vincent Massol

On Mar 18, 2008, at 3:22 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2008-03-18 15:22:42 +0100 (Tue, 18 Mar 2008) > New Revision: 8601 > > Modified: > xwiki-platform/xwiki-plugins/trunk/spacemanager/src/main/java/ > xwiki-platform/xwiki-plugins/trunk/swizzle/src/main/java/ > xwiki-products/xwiki-enterprise-manager/trunk/distribution-test/ > selenium-tests/ > xwiki-products/xwiki-enterprise-manager/trunk/distribution-test/ > xmlrpc-tests/ > Log: > Add Eclipse settings to svn:ignore > > > Property changes on: xwiki-platform/xwiki-plugins/trunk/spacemanager/ > src/main/java > ___________________________________________________________________ > Name: svn:ignore > + META-INF > > > > Property changes on: xwiki-platform/xwiki-plugins/trunk/swizzle/src/ > main/java > ___________________________________________________________________ > Name: svn:ignore > + META-INF META-INF should definitely not be added. Can you rollback? Thanks -Vincent

17 years, 6 months

1
0
0 0

[xwiki-devs] [Proposal] Improve Wiki Administration

by Jean-Vincent Drean

Hi XWikiers, We'd like to refactor the wiki & space administration for XE 1.4. Layout drafts and full proposal are available here : http://dev.xwiki.org/xwiki/bin/view/Design/ImproveWikiAdministration Summary : * Display the administration features in wiki pages, in view mode (ie : move code from the admin templates to wiki pages) * Merge the current XWiki.WebHome items with the current Administration features in the new UI * Merge the import / export features in the same page * Put the Panels list and PanelWizard in the new UI Tech : * new XWiki.WebHome : direct links (with big icons) to admin categories (a la Windows control panel) * A main administration sheet : XWiki.AdministrationSheet (may be with cascading admin sheets beyond) * Inclusion of XWiki.AdministrationSheet in XWikiPreferences (global prefs) * Inclusion of XWiki.AdministrationSheet in all WebPreferences (quick access to space admin) Questions : * Do we add an "Administration" entry in the top menu bar ? With 2 dropdown items : ** current space administration ** wiki administration * Do we really need the "big icons" page (since all the categories are available from the left column) ? wdyt ? Thanks, JV.

17 years, 6 months

2
3
0 0

[xwiki-devs] New Observation component: Usage scenarios

by Sergiu Dumitriu

Hi, How do you feel about the next usage scenarios for the observation component? A. Simple observing of changes This is the most common usage of the old notification mechanism. It allows a listener to see when something gets changed. It receives as the source the changed document, from which it can get the original document (there's a doc.getOriginalDocument() method for this). For the moment, the data argument is the context, as it is still a vital object for most of the code, and it has to be passed around all the time. The event will hold the type of change, like adding a new document, deleting, or just saving a new version. In the future I'd like to increase the granularity, to make this "change" a set of basic changes, to be able to say that (object added, attachment removed, content changed) is what happened to the document (see http://jira.xwiki.org/jira/browse/XE-213 too). With this event, a listener can then update some data indexer, like the Lucene plugin does, or send the new documents/attachments to a repository, or send a mail with the new code, or ping on IRC. B. Simple observing of actions This is also implemented in the old notification mechanism. It allows a listener to monitor actions. It receives as the source the affected document, and as the additional data the same context, as it is needed. The event holds the action name, and I'd like to add the full URL, too, as other important information might be in there. I don't know if sending the complete request object is a good idea, but I think we should be able to obtain it somehow. With this event, a listener can update some statistics, refresh some caches or cleanup some indexes, send an attachment to another repository (like SVN), or, based on the URL, it can be used to take some action, like if the action was "createspace" and the "notify=admins" parameter was given in the request, then the observer can send the notifications, without polluting the application code with the checks and mail sending calls. C. Precondition/Postcondition enforcing The previous two use cases allow a simple ping that something has already happened. (Actually, the listeners can also change the passed document, as the actual object is sent.) But I'd like to be able to write a listener that can say "this is not allowed, please stop this action", or "these changes are not OK, don't save this document". So, a precondition can be that "/save/" cannot be performed between 6PM and 7AM, which would be a needed feature in some companies, or that "/view/" cannot be performed on the "SectionA" space from the IP addresses like 192.168.2.*, which belongs to the SectionB users (these are action events). And a postcondition can be that the XWiki.XWikiPreferences can only be updated by changing XWikiGlobalRights objects, other types of changes can only be performed by a superadmin only, or that adding some content that looks like spam is not allowed (these are document events). So, on top of the previous use cases, I'd like to add a "phase" to the events, which indicates if the event is sent before or after the change (or we can just add new events), and a new type of exception thrown by the listeners, which is not ignored. Right now, if a listener throws an exception, it is ignored. This exception, when received by the code that sends the notification, should stop the normal processing and display "action not allowed" + ex.getMessage to the user. D. Rendering hooks While working on the SkinExtensions and trying to write a better #toc macro, I was faced with the problem that there's no way a plugin can change the rendered content at the end. Yes, it can alter it line by line, and in theory there is an endRenderingHook sent with the content, but that is actually buggy, as an empty string is sent instead of the content, and the result is discarded. Still, even if fixed, this is sent only for *rendered* content, not *parsed* content. My initial idea was to change the PluginInterface by adding two new methods that will be called before and after the content was generated, but that is a bad idea, since the PluginInterface is already too big and has too many types of methods. And since the new rendering component is not yet available, I thought that we can also use events for this. So, instead of writing new methods in the PluginInterface, we can add other type of events, which gets sent in the parsing/rendering process. That way, we don't need to have a plugin that implements all these methods, and adding a new feature will require just sending a new type of event, instead of changing an interface (which is dangerous). The source would be an object holding the string, which can be modified by the listeners. Other information could be the content document, if there is one, the rendering/parsing context, anything else? E. Other generic events Like FlushCacheEvent, StartupEvent, ShutdownEvent, VirtualInitEvent, VirtualShutdownEvent (sent when a wiki is deleted by the WikiManagerEvent), Application[Added/Enabled/Disabled/Removed]Event (sent by the ApplicationManager), Space[Added/Removed]Event (sent by the SpaceManagerPlugin), etc. Comments, please? -- Sergiu Dumitriu http://purl.org/net/sergiu/

17 years, 6 months

3
5
0 0

[xwiki-devs] XWiki Goodies Coming Ahead !!

by Guillaume Lerouge

Hi fellow XWikiers, We teased you with a few exclusive t-shirt pictures 2 weeks ago... The time has now come to offer our community the opportunity to enjoy them too ! We have setup a cafepress account for XWiki, available at http://www.cafepress.com/xwiki . You'll be able to find there t-shirts, mugs, caps and many more goodies to play with ! We have put a small profit margin on most products. The money received through the sale of those goodies will go straight back into the XWiki Open-Source Community development effort, under a format yet to define (but the idea will be to reward the most active XWiki committers & contributors from outside of XWiki SAS - the company). One address : http://www.cafepress.com/xwiki - enjoy ! I've also added the XWiki logos & other fun images on this page for the community to enjoy : http://www.xwiki.org/xwiki/bin/view/Main/Goodies We hope to see you all wearing XWiki apparel soon ;-) On behalf of the XWiki Development Team, Guillaume PS : Ricardo, we'd be glad to see the XWiki logo on your sports teams shirts :-) You'll find all the images you'll need on the Goodies page mentioned above. Don't forget to send us the pictures when you wear them - and win ! :-)

17 years, 6 months

2
1
0 0

[xwiki-devs] [Proposal] Rename Context.isVirtual and XWiki.isVirtual

by Thomas Mortagne

Hi all, After reviewing the code and doing some debug I found that Context/XWikiContext.isVirtual and XWiki.isVirtual are two things different : * context : "is not in the main wiki" * xwiki : "platform is in virtual mode" This is very disturbing and i'm pretty sure context.isVirtual is used in the wrong way at some places... Plus, context does not need to store a "virtual" variable (like it does actually), it just need to compare getMainXWiki and getDatabase. I propose to rename XWiki method to "isVirtualMode" and refactor XWikiContext/Context isVirtual/setVirtual to "isMainWiki" and of course deprecate old methods. WDYT ? PS : I already asked that in http://jira.xwiki.org/jira/browse/XWIKI-1874 but I think it deserve a mailing list thread -- Thomas Mortagne

17 years, 6 months

3
3
0 0

[xwiki-devs] [ANN] XWiki Workspaces Milestone 1 Released

by Jerome Velociter

The XWiki development team is pleased to announce the release of XWiki Workspaces Milestone 1, Go grab it at http://www.xwiki.org/xwiki/bin/view/Main/Download XWiki Workspaces is a new product focusing on easy collaboration through workspaces and their applications : Wiki, Blog, Photo Galleries and Files sharing. This first milestone implements the initial feature set of Workspaces, you can find more about it on http://workspaces.xwiki.org For more information about this release, including links to installation instructions and to Workspaces JIRA project, read the releases notes at http://www.xwiki.org/xwiki/bin/view/Main/ReleaseNotesWorkspaces10M1 Thanks, -The XWiki dev team

17 years, 6 months

1
0
0 0

[xwiki-devs] Using Apache BasicAuth or mod_ssl's "FakeBasicAuth" and MyOpenID (was Re: logout)

by Niels Mayer

what about a more generic version of the prior question: Assuming one already has an apache (httpd) based site using "HTTP Basic Authorization" feature in apache, what is the technique for allowing already authenticated users to use that same authentication in Xwiki? This assumes some means of mapping the basic auth name to the xwiki user name, which is trivial. In other words you could use something like mod_auth_mysql<http://www.howtoforge.com/mod_auth_mysql_apache2_debian>to alllow password-based access to restricted portions of a website (or entire thing if .htaccess at toplevel) via apache. More security or extranet access can be granted via mod_ssl combined with client certificates & "fake basic authentication"<http://www.modssl.org/docs/2.8/ssl_reference.html#SSLOptions> : - FakeBasicAuth When this option is enabled, the Subject Distinguished Name (DN) of the Client X509 Certificate is translated into a HTTP Basic Authorization username. This means that the standard Apache authentication methods can be used for access control. The user name is just the Subject of the Client's X509 Certificate (can be determined by running OpenSSL's openssl x509command: openssl x509 -noout -subject -in *certificate*.crt). Note that no password is obtained from the user. Every entry in the user file needs this password: `` xxj31ZMTZzkVA'', which is the DES-encrypted version of the word ` password''. Those who live under MD5-based encryption (for instance under FreeBSD or BSD/OS, etc.) should use the following MD5 hash of the same word: ``$1$OXLyS...$Owx8s2/m9/gfkcRVXzgoE/''. in other words you have an external table mapping the client-certificate's DN, which can be an elaborate string like "/O=ufl.edu/OU=Employees/C=US/O=University of Florida/CN=ANDREW MEYER/Email= dontasemebro(a)ufl.edu|" and this would provide authentication for user 'Xwiki.AndrewMeyer' and grant that user access based on the associated xwiki account. With the advent of https://www.myopenid.com the latter client-certificate, SSL-based authentication ought to be considered as a nice "universal login identity".... IMHO it provides a consistent way of handling identity across a wide variety of sites. In the past i've setup http://ipssources.com which uses 2-factor auth via HP "Digital Badge" -- similar can be achieved, much more easily, and cheaply, via MyOpenID. Their system is indeed like HP's "digital badge" except that it's free and works across multiple websites. MyOpenID has potential of being a useful service if it catches on.... When i used it, it smoothly sent me a client-cert and appears to provide a decent API for management: You have the following certificates: Label Serial Number Created Revoked gnuvelle BF1E 2008-02-11 16:32:29.195635 Revoke this Certificate Thus making the potentially-difficult task of issuing and installing client certificates in the user's browser a no-brainer (at least in firefox). If they've correctly handled the MS/vs-the-world issues so that IE and Netscape and mac users can access the web as ubiquitously as advertised, they've won most of the "client auth" battle IMHO.... -- Niels http://nielsmayer.com On Sat, Mar 15, 2008 at 8:47 PM, Glenn Everitt <Glenn.Everitt(a)compuware.com> wrote: > > Thanks for the advice on changing the global.vm, sadly the authentication > is > proprietary and wouldn't help anyone else. Thanks again. - Glenn Everitt > > > Ludovic Dubost-2 wrote: > > > > > > Hi, > > > > There is no change the XWiki logout page is going to have any effect > > when you are using Apache level auth. > > Best is just to change the global.vm and link to your logout page with > > the xredirect param and have your logout page redirect to that url in > > the xredirect param. > > > > What type of authentication are you using in your server ? If it's a > > non-proprietary one, it might be nice to document your config on > > xwiki.org. > > > > Ludovic > > > > Glenn Everitt wrote: > >> I am using Apache level authentication and the > >> AppServerTrustedAuthServiceImpl using getRemoteUser to get into XWiki > and > >> I > >> have this working. I need to call something like a logout.jsp to > >> invalidate > >> the session and cleanup. I thought I should use the > >> xwiki.authentication.logoutpage=/[^/]+/logout/* > >> in xwiki.cfg. I can't tell what this is doing and whether it is > related > >> to > >> ... > >> > >> The velocity template global.vm seems to generate the logout link on > the > >> main menu. > >> #set($logouturl = $xwiki.getURL("XWiki.XWikiLogout","logout", > >> "xredirect=$util.encodeURI($logredir)")) > >> $!logouturl $!msg.get("logout") #sep() > >> > >> Any clues on how to handle logout would be greatly appreciated. > >> > >> Thanks > >> Glenn Everitt > >> > >> > > > > > > -- > > Ludovic Dubost > > Blog: http://blog.ludovic.org/ > > XWiki: http://www.xwiki.com > > Skype: ldubost GTalk: ldubost > > > > _______________________________________________ > > devs mailing list > > devs(a)xwiki.org > > http://lists.xwiki.org/mailman/listinfo/devs > > > > > > -- > View this message in context: > http://www.nabble.com/logout-tp16040945p16075537.html > Sent from the XWiki- Dev mailing list archive at Nabble.com. > > _______________________________________________ > devs mailing list > devs(a)xwiki.org > http://lists.xwiki.org/mailman/listinfo/devs >

17 years, 6 months

1
0
0 0

[xwiki-devs] logout

by Glenn Everitt

I am using Apache level authentication and the AppServerTrustedAuthServiceImpl using getRemoteUser to get into XWiki and I have this working. I need to call something like a logout.jsp to invalidate the session and cleanup. I thought I should use the xwiki.authentication.logoutpage=/[^/]+/logout/* in xwiki.cfg. I can't tell what this is doing and whether it is related to ... The velocity template global.vm seems to generate the logout link on the main menu. #set($logouturl = $xwiki.getURL("XWiki.XWikiLogout","logout", "xredirect=$util.encodeURI($logredir)")) $!logouturl $!msg.get("logout") #sep() Any clues on how to handle logout would be greatly appreciated. Thanks Glenn Everitt -- View this message in context: http://www.nabble.com/logout-tp16040945p16040945.html Sent from the XWiki- Dev mailing list archive at Nabble.com.

17 years, 6 months

2
2
0 0

[xwiki-devs] my metadatalucenetutorial is completed now...

by jvivien.m2 jvivien.m2

hello, I think I have completed my MetadataLuceneTutorial by now. Could you please tell me : - if it is relevant to the xwiki community ? otherwise I can remove it - if it is not clear enough to meet the docs standards. For example : too many subjects at the same time ? do the code sources need to be rewritten so as to show more clearly where is the customization ? - if it could be submitted, and to whom. To the devs list ? to the XWiki team only ? If you have more or less already approved it, do you even plan to leave it as a tutorial, or do you want to see it as a description of a possible improvement to the core ? I think no one would have time to tutor me right now, otherwise I would be ready to contribute. If no one has time then it is better in my opinion to leave it as a tutorial, which will show people how things work. Just tell me if this is the case - its okay, there are so many more important things to do for the team. Thanks a lot ! -- Jean-Vivien MAURICE Ingénieur Informatique et Gestion, Polytech'Montpellier (ISIM) E-mail : jean.vivien.maurice(a)gmail.com Tél. : +33 6 76 70 88 02 (or else : +33 6 79 46 45 24) Skype : jean.vivien

17 years, 6 months

1
0
0 0

[xwiki-devs] [ANN] First DocHour results

by Vincent Massol

Hi everyone, The first DocHour has been very successful IMO. Here are what we've done all together: * Vincent - "Document how to improve performance by using Apache and mod-deflate/mode-expire and mod-proxy-ajp" - http://jira.xwiki.org/jira/browse/XWIKI-2176 * Vincent - "Document the {rss} macro" - http://jira.xwiki.org/jira/browse/XWIKI-1340 * Vincent - http://www.xwiki.org/xwiki/bin/view/FAQ/PrivateRssFeeds * Jean-Vincent - http://dev.xwiki.org/xwiki/bin/view/Main/ because devs deserve a nice homepage ;) * StephaneB - a short glance over the combination between velocity language and XWiki API functions (http://dev.xwiki.org/xwiki/bin/view/Drafts/ObjectInPage ) - Not finished. * Evelina - document the new users and groups management (http://jira.xwiki.org/jira/browse/XWIKI-1867 ) * Guillaume - wrote & documented the Video Macro on XWiki.org - http://code.xwiki.org/xwiki/bin/view/Macros/VideoMacro * Jerome - "Write a tutorial for newcomers on how to create Java selenium tests." - http://jira.xwiki.org/jira/browse/XWIKI-1351 started a draft at http://dev.xwiki.org/xwiki/bin/view/Drafts/WritingSeleniumsTestsForXWiki - Not finished * Marius - "Document the Core APIs properly" - http://jira.xwiki.org/jira/browse/XWIKI-2187 - Not finished * ThomasM - improve wiki creation documentation with a combination of http://jira.xwiki.org/jira/browse/XAWM-48 and http://manager.xwiki.org/xwiki/bin/view/AdminGuide/CreateNewWiki * Ludovic/Guillaume - create a package for the Polls Application and document it on XWiki.org - http://code.xwiki.org/xwiki/bin/view/Applications/PollsApplication * Anca - updated and brought small improvements to the FAQ Tutorial: added links to useful pages and added code explanations here and there. * Asiri - Building XEclipse with Eclipse at http://code.xwiki.org/xwiki/bin/view/Extensions/XEclipseExtension - Not finished Thanks everyone who participated! This is great and helped a lot. I'd like to do that again in about a month. Now it would be nice to finish the outstanding issues started in this DocHour namely: * StephaneB - a short glance over the combination between velocity language and XWiki API functions (http://dev.xwiki.org/xwiki/bin/view/Drafts/ObjectInPage ) - Not finished. * Jerome - "Write a tutorial for newcomers on how to create Java selenium tests." - http://jira.xwiki.org/jira/browse/XWIKI-1351 started a draft at http://dev.xwiki.org/xwiki/bin/view/Drafts/WritingSeleniumsTestsForXWiki - Not finished * Marius - "Document the Core APIs properly" - http://jira.xwiki.org/jira/browse/XWIKI-2187 - Not finished * Asiri - Building XEclipse with Eclipse at http://code.xwiki.org/xwiki/bin/view/Extensions/XEclipseExtension - Not finished. Asiri could yo please move the building information to the Buliding page as I had suggested please? Thanks again -Vincent

17 years, 6 months

3
5
0 0

[xwiki-devs] LDAP authentication issues!!

by Kamna Jain

Hello, We have been having some issues with the LDAP authentication to our XWiki instance. Here is the portion from xwiki.cfg: xwiki.authentication.ldap=1xwiki.authentication.ldap.authclass=com.xpn.xwiki.ldap.authentication.XWikiLDAPAuthServiceImplxwiki.authentication.ldap.server=domain.company.comxwiki.authentication.ldap.check_level=1xwiki.authentication.ldap.port=389xwiki.authentication.ldap.base_DN=dc=domain,dc=company,dc=comxwiki.authentication.ldap.bind_DN=domain\\{0}xwiki.authentication.ldap.bind_pass={1}xwiki.authentication.ldap.UID_attr=sAMAccountNamexwiki.authentication.ldap.fields_mapping=name=sAMAccountName,last_name=sn,first_name=givenName,fullname=displayName,email=mail,ldap_dn=dn We have two separate installations on two different machines: One is the standalone installation (for the first time user) and in that I could configure the LDAP authentication with a particular domain at our company. But, it does not work if I change the domain. Now, the other is an installation of the WAR file with Tomcat 6.0 and Oracle 10g DB. In this setup, there are some issues. Currently xWiki may refresh the login page when logging through ldap without indicating whether authentication was successful or not. With the current configuration 1. users attempts login 2. Some users are able to log in, otherwise - log in pages refreshes the page, providing no indication to the user of any change from the login attempt 3. no information is provided to xwiki.log 4. the user's username is then listed as part XWikiAllgroup and the user's wiki page is created the with correct LDAP information - There are variations to this error. Some users experience an "access denied" error on log in. Their usernames are added to XWIkiAllGroup for each successive log in. Could anyone throw any light on why this might be happening? Do we need to make any changes to the LDA confi. part in xwiki.cfg? Any help will be highly appreciated. Thanks

17 years, 6 months

2
1
0 0

Re: [xwiki-devs] [xwiki-notifications] r8519 - in xwiki-platform/xwiki-tools/trunk: xwiki-configuration-resources xwiki-jetty-resources xwiki-license-resources xwiki-packager-plugin xwiki-shared-tests

by Sergiu Dumitriu

vmassol (SVN) wrote: > Author: vmassol > Date: 2008-03-14 23:50:09 +0100 (Fri, 14 Mar 2008) > New Revision: 8519 > > Modified: > xwiki-platform/xwiki-tools/trunk/xwiki-configuration-resources/ > xwiki-platform/xwiki-tools/trunk/xwiki-jetty-resources/ > xwiki-platform/xwiki-tools/trunk/xwiki-license-resources/ > xwiki-platform/xwiki-tools/trunk/xwiki-packager-plugin/ > xwiki-platform/xwiki-tools/trunk/xwiki-shared-tests/ > Log: > more svn ignores > > > Property changes on: xwiki-platform/xwiki-tools/trunk/xwiki-configuration-resources > ___________________________________________________________________ > Name: svn:ignore > - target > *.ipr > *.iml > *.log > .classpath > .project > nbproject > .settings > > + target > *.ipr > *.iml > *.log > .classpath > .project > nbproject > .settings > target-eclipse > Shouldn't we just add these kind of files/directories to the subversion config file? I'm pretty sure we'll never have a target-eclipse directory that will need to be committed. -- Sergiu Dumitriu http://purl.org/net/sergiu/

17 years, 6 months

2
2
0 0

[xwiki-devs] Roadmap for XE 1.4

by Vincent Massol

Hi everyone, I'd like everyone's input for defining the XE 1.4 roadmap both on the general objectives and specific features/bugs to implement/fix. Here's my first take below. Please comment on it and add other stuff. This is a brainstorming session. Then we can start assigning committers/contributors to goals/issues. General Goals: ============ * Bug fixes ** Go from 240 in JIRA for Core down to 180 on XE 1.4 release date * Better performance ** Run XE with a profiler and find bottlenecks ** Reduce number of database calls ** Improved page loading (JV) ** Make Stats usable on xwiki.org (ThomasM) * More automated tests ** More selenium tests ** Add tests on Tomcat 6.x as part of the CI build ** Add tests on Windows and with IE6 and IE7 as part of the CI build * No new features in general Of course there are some goals that are always valid irrelevant on any release and that we should keep in mind: * More tests * Better javadoc * More documentation on xwiki.org * Code cleanup/refactoring * Extract more plugins from core into plugins proper Specific issues to implement/fix ======================== * Add support for removing class properties (http://jira.xwiki.org/jira/browse/XWIKI-99 ) * (optional - depending on availability) - New rendering rewrite (http://jira.xwiki.org/jira/browse/XWIKI-654 ) * (optional - depending on availability) - Interface extensions (http://dev.xwiki.org/xwiki/bin/view/Design/InterfaceExtensions ) * Add any other critical issue here Thanks -Vincent

17 years, 6 months

7
15
0 0

[xwiki-devs] XWiki Attachments

by Kamna Jain

I was wondering if the files that are uploaded on XWiki are stored in any particular folder on the server? Or is it just the tables in the DB that have information on them? We are exploring the ways in which the files uploaded can be directly added to a SVN repository. For this, I need to know the location of the files once they are uploaded. Thanks

17 years, 6 months

3
2
0 0

Re: [xwiki-devs] [Issue] Commented: (XWIKI-1573) A custom version of swizzle-confluence should be added to the xwiki maven repository

by Sergiu Dumitriu

dede (JIRA) wrote: > > dede commented on XWIKI-1573: > ----------------------------- > I'm tired of this spammer. I keep deleting his account, and he keeps creating it. I'm trying a new strategy: I changed his password. Let's see if that works. -- Sergiu Dumitriu http://purl.org/net/sergiu/

17 years, 6 months

1
0
0 0

[xwiki-devs] [VOTE] remove api.Attachment#getArchive() and wrap #getAttachmentRevision

by Artem Melentyev

Hi, devs. While reviewing our attachment archive implementation I found following methods in com.xpn.xwiki.api.Attachment: /** * @return the rcs archive of the attachement */ public Archive getArchive() { return attachment.getArchive(); } It returns unwrapped JRCS archive which Has modify methods. So user can change attachment archive without proper rights. Also there are public archive-specific methods in api.Attachment such as getVersions, getAttachmentRevision. So I found no usecases of getArchive method. This method can be replaced by api.Attachment.getAttachment().getArchive() with checking programming right. next method: public XWikiAttachment getAttachmentRevision(String rev) throws XWikiException { return attachment.getAttachmentRevision(rev, getXWikiContext()); } returns unwrapped XWikiAttachment, but should return api.Attachment. So i propose to delete api.Attachment#getArchive() and modify getAttachmentRevision to return Attachment. Another question: is this fix needed for 1.3 brunch? Here is my +1 for fix it in trunk. -- Artem Melentyev

17 years, 6 months

4
4
0 0

[xwiki-devs] [VOTE] Release workspaces milestone 1

by Jerome Velociter

Hi devs, As planned in the roadmap, I would like to release the first milestone of XWiki Workspaces tonight. Here is my +1 for it. Jerome.

17 years, 6 months

6
5
0 0

[xwiki-devs] [VOTE] Release SpaceManager plugin v1.0

by Jerome Velociter

Hello, I'd like to release the 1.0 version of the SpaceManager plugin. You can see the features it implements on http://code.xwiki.org/xwiki/bin/view/Plugins/SpaceManagerPlugin. I will update this document with installation notes and javadoc API as soon as it is released. Here is my +1 for it. Regards, Jerome.

17 years, 6 months

5
7
0 0

Re: [xwiki-devs] [Issue] Created: (XWIKI-2116) Make XWiki.XWikiAllGroup a "special" group, rather than a real document with objects attached.

by Erin Schnabel

I was asked to post to the list about this.. things have been busy, so it's taken me awhile. There are a few things that really bug me about the XWikiAllGroup: 1) It requires an XWikiGroups object to be created for every registered user, which is a pain in the butt when there are thousands 2) It is possible for the XWikiAllGroup to get out of sync with actual registered users: When users are deleted, it does not automatically remove the corresponding object from XWikiAllGroup, and if there is a strange window with the cache (which I've seen happen) objects for new users are not correctly added to the XWikiAllGroup document. The XWikiAllGroup is special (just as XWikiGuest is special). It's my view that the document a) shouldn't have to really exist, and b) shouldn't actually have to have XWikiGroups objects for every user attached to it. If someone is a valid user, they're in XWikiAllGroup.. that's it. The default contents of the XWikiAllGroup document could either be a link to the XWikiUsers page, or a repeat of the query displaying all of the users in the system. So it's my thought that the auth code should be modified to treat XWikiAllGroup as a special entity in the future. I know I'll be more than happy to delete the XWiki.XWikiAllGroup document as soon as I have the chance. On Wed, Feb 13, 2008 at 11:32 PM, Erin Schnabel (JIRA) <jira(a)xwiki.org> wrote: > Make XWiki.XWikiAllGroup a "special" group, rather than a real document with objects attached. > ---------------------------------------------------------------------------------------------- > > Key: XWIKI-2116 > URL: http://jira.xwiki.org/jira/browse/XWIKI-2116 > Project: XWiki Core > Issue Type: Bug > Components: Authentication and Rights Management > Affects Versions: 1.2.1, 1.2, 1.1, 1.0 > Reporter: Erin Schnabel > > > I've seen XWiki.XWikiAllGroup get out of sync: There are users in XWIki.XWikiAllGroup that don't exist, and users that exist that aren't in XWIki.XWikiAllGroup. > > It seems to me that XWiki.XWikiAllGroup is special. It should be treated in auth code as a magic word, like superadmin or XWiki.XWikiGuest, to mean "any user that exists in the DB for that wiki" (XWikiGuest doesn't live in the DB.. ). > > These "AllGroups" would still hold different members: xwiki:XWiki.XWikiAllGroup, xwiki_virtual:XWiki.XWikiAllGroup > > -- > This message is automatically generated by JIRA. > - > If you think it was sent incorrectly contact one of the administrators: http://jira.xwiki.org/jira/secure/Administrators.jspa > - > For more information on JIRA, see: http://www.atlassian.com/software/jira > > > -- 'Waste of a good apple' -Samwise Gamgee

17 years, 6 months

3
2
0 0

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs