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

[xwiki-devs] Google Summer Of Code 2013

by lavinia bobonete

Hi, My name is Lavinia Bobonete and I am now pursuing a Master degree in Computer Science, at Politehnica University of Bucharest. I have a couple of years experience with Java (both SE and EE) and JavaScript (JavaScript MVC especially), so I think that there shouldn't be any programming barriers. I've looked over your proposed projects and there is more than one project that catches my attention: Wiki Collections, Live Notifications, Messaging Feature and Extension Repository. These all correspond to my area of interest. But I have a question: is there any project with a higher priority in the development of XWiki? And secondly: how can I start getting involved? I'm looking forward to hearing from you and being a valuable part of the community, Lavinia Bobonete

12 years, 5 months

2
1
0 0

[xwiki-devs] [Reminder] BFD #16

by Vincent Massol

We're only 23 bugs away from succeeding in catching up on 2 years! We can make it during this BFD! See http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=10352 Dashboard for BFD#16: http://jira.xwiki.org/secure/Dashboard.jspa?selectPageId=11507 Let's do it! Thanks -Vincent

12 years, 5 months

1
3
0 0

[xwiki-devs] [Proposal] Flavor's vision + Next steps

by Vincent Massol

Hi devs, Caty, Thomas, Marius and myself have had a brainstorming session today about Flavors. Here's the proposal that came out of it: * Remove notion of XE/XEM distributions. The distribution is just "XWiki" * XWiki becomes an empty shell (as it is already when you download the WAR), even when you download the standalone distribution * Generate distributions in xwiki-platform, maybe in xwiki-distributions with installers inside and some functional tests (but most func tests will be with flavors) * Remove xwiki-enterprise and xwiki-manager and introduce xwiki-flavors/ in xwiki-platform * Introduce notion of Categories for extensions (similar to the category concepts in wiki macros) * Flavors will be extensions categorized as "flavors" (using the Categories system) * In the future we'll also need a new Maven <paclaging> type to represent a grouping of extensions with no specific content * Display Flavors in DW first steps and ask user to choose which one they want to specialize their wiki * First 2 flavors we need: Workspaces and Knowledge Base (closest to the current XE but without Blog). We need to define precisely the first version of these 2 flavors We also agreed that the main work to be done before we can really have flavors is to implement Categories for extensions. We'll need to decide when we start working on this in our roadmap but probably not before 5.2 anyway since 1) it'll be Marius and Thomas who would work on this and 2) Thomas has to work on performance import/export and Marius needs to work on AWM, probably both in 5.1 (roadmap not defined yet). WDYT? Thanks -Vincent

12 years, 5 months

4
8
0 0

[xwiki-devs] Fwd: MEDIA ALERT: The Apache Struts Project Announces Apache Struts™ 1 End-Of-Life

by Sergiu Dumitriu

We really should stop using Struts 1. -------- Original Message -------- Subject: MEDIA ALERT: The Apache Struts Project Announces Apache Struts™ 1 End-Of-Life Date: Tue, 9 Apr 2013 14:01:20 +0100 (BST) From: Sally Khudairi <sk(a)apache.org> Reply-To: Sally Khudairi <sk(a)apache.org> To: announce(a)apache.org <announce(a)apache.org> >> this announcement is also available online at http://s.apache.org/7zi Apache Struts 2 recommended as an elegant Open Source, extensible successor framework for creating enterprise-ready Java Web applications Forest Hill, MD –9 April 2013– WHO: The Apache Software Foundation's Apache Struts Project, creators of leading Open Source solutions for creating Java web applications. WHAT: The Struts™ 1.x Web framework has reached its end-of-life (EOL) and is no longer officially supported. Created in 2000 to provide an improved development experience over pure Java Server Pages (JSP) utilization, Apache Struts 1 soon became the de-facto standard for Java-based Web application development. Numerous companies world-wide adopted Struts 1 as a strategic platform, even after JSF (Java Server Faces) was introduced as a standardized Java EE framework for Web application development. Its popularity was so prevalent in the early 2000s, most job offerings in the space of Java-based Web technology required Struts 1 as a must-have skill. Today, many important Websites and Web-based user interfaces continue to rely on Struts 1 technology. In addition, many popular Web frameworks, such as Spring MVC and WebWork, were significantly inspired by Struts 1. WHEN: The Apache Struts Project Management Committee is not aware of any urgent issues posing the immediate need to eliminate Struts 1 usage. However, the project's EOL status signifies that security and bug fixes will no longer be provided effective immediately. The Apache Struts project recommends new projects to be developed using Struts 2 as opposed to Struts 1. While any action-based Java web framework is a potential candidate to re-use Struts 1 architectural experience or migrate existing Struts-1-based applications, users are highly advised to investigate Struts 2 as a successor framework. WHY: Struts 2 is modern, highly decoupled, feature rich, well maintained, and successfully running in many mission-critical projects globally. It shares the same basic principles with Struts 1, and offers a highly improved architecture, API, and solution portfolio. WHERE: The last release of Apache Struts 1 is version 1.3.10 from December 2008. All software downloads, notices, and updates are available at the Apache Struts project homepage at http://struts.apache.org/. NEXT STEPS: The Struts community continues its focus on pushing the Apache Struts 2 framework forward, with as many as 23 releases to date. Availability and Oversight Apache Struts software is released under the Apache License v2.0, and is overseen by a self-selected team of active contributors to the project. A Project Management Committee (PMC) guides the Project's day-to-day operations, including community development and product releases. Apache Struts source code, documentation, mailing lists, and related resources are available at http://struts.apache.org/. About The Apache Software Foundation (ASF) Established in 1999, the all-volunteer Foundation oversees nearly one hundred fifty leading Open Source projects, including Apache HTTP Server — the world's most popular Web server software. Through the ASF's meritocratic process known as "The Apache Way", more than 400 individual Members and 3,500 Committers successfully collaborate to develop freely available enterprise-grade software, benefiting millions of users worldwide: thousands of software solutions are distributed under the Apache License; and the community actively participates in ASF mailing lists, mentoring initiatives, and ApacheCon, the Foundation's official user conference, trainings, and expo. The ASF is a US 501(3)(c) not-for-profit charity, funded by individual donations and corporate sponsors including AMD, Basis Technology, Citrix, Cloudera, Facebook, Go Daddy, Google, HP, Hortonworks, Huawei, IBM, InMotion Hosting, Matt Mullenweg, Microsoft, PSW Group, SpringSource/VMware, WANdisco, and Yahoo!. For more information, visit http://www.apache.org/ or follow @TheASF on Twitter. "Apache", "Struts", "Apache Struts", and "ApacheCon" are registered trademarks or trademarks of the Apache Software Foundation in the United States and/or other countries. All other brands and trademarks are the property of their respective owners. # # # Contact: Sally Khudairi Vice President The Apache Software Foundation press(a)apache.org +1 617 921 8656 >> You are receiving this message because you are subscribed to the Apache Announcements List to unsubscribe, send an email from the subscribed address to <announce-unsubscribe(a)apache.org>. For more information, visit http://apache.org/foundation/mailinglists.html#foundation-announce

12 years, 5 months

1
0
0 0

[xwiki-devs] [GSOC] XWiki has been accepted as a mentoring organization for Google Summer of Code 2013

by Ecaterina Moraru (Valica)

Hi devs and users, I would like to announce that XWiki has been accepted as a mentoring organization for Google Summer of Code 2013. This is our 8th year participating in the program. If you are an interested student, please have a look over the list of proposed projects and feel free ask any questions on the devs(a)xwiki.orglist. http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/WebHome#HProposedPro… If you plan to be a mentor this summer, don`t forget to *register* as such on XWiki's melange page http://www.google-melange.com/gsoc/org/google/gsoc2013/xwiki The program's timeline is available at http://www.google-melange.com/gsoc/events/google/gsoc2013 Additional information can be found at http://gsoc.xwiki.org or in the blog post http://www.xwiki.org/xwiki/bin/view/Blog/XWiki+is+participating+in+Google+S… Thanks, Caty

12 years, 5 months

2
1
0 0

[xwiki-devs] Potentially missing deps on translation macro module

by Vincent Massol

Hi devs, Recently we've done a big work of converting the old $msg into $services.localization or {{translation/}}. Every time we've done that in a module we need to add a dependency in its pom on the appropriate localization module. I haven't checked fully if we've done this or not but it's possible that some functional tests don't fail because they don't test everything so we need to review the POMs. Thanks -Vincent

12 years, 5 months

2
2
0 0

[xwiki-devs] Getting documents list of a Blog Category

by Bey Youcef

Hi All, I'm trying to do the following task without any success. Getting a list of documents of a specific Blog Category (Let's say Category "C"). After getting all documents of "C", then getting from each document the "Summary" field. Would it be possible to lead me on how to do this task in Velocity? Any help will be strongly appreciated. ps. I'm working on Google Map extension for supporting several positions; I will push it as soon as I finish it. Best wishes Youcef

12 years, 5 months

2
2
0 0

[xwiki-devs] Should we imply more than the delete right for document creator ?

by Denis Gervalle

Hi devs, While introducing the new security module, we have added a new right named "creator", only applicable at document level, it is automatically applied on documents for their creator. This right is not really checked for itself, but it imply the delete right with a tie resolution policy of allow, and a inheritance policy of not deniable. This give a document creator the right to delete the document whatever other policies could say about him. Since having only delete right on a document does not seems really logical, I am wondering if it would not be good to make the creator right also imply the view, and the edit right. This would give to document creators consistant minimal right on their documents, what ever the policy of the wiki is. WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

12 years, 5 months

2
1
0 0

[xwiki-devs] [Reminder] BFD #15 tomorrow 4th of April 2013

by Vincent Massol

BTW, it seems the BFD #14 blog post and addition on http://dev.xwiki.org/xwiki/bin/view/Community/DevelopmentPractices#HXWikiDa… are missing. Could someone add them? Thanks -Vincent

12 years, 5 months

4
5
0 0

[xwiki-devs] Mobile XWiki Client and Mobile Skin repositories on xwiki-contrib

by Ludovic Dubost

As discussed a while ago, I'm finally made public the Mobile XWiki Client code I've been working on. I've transfered the repository as well as the mobile skin repository to xwiki-contrib https://github.com/xwiki-contrib/mobile-standardxwikiclient https://github.com/xwiki-contrib/skin-mobile-simple The next step for the mobile client is a rework to be: 1/ More modular to allow for additional module and UI changes to allowed by plugins. 2/ A rework of the network layer to be able to queue requests to XWiki and manager errors and retries as well as login. Ludovic -- Ludovic Dubost Founder and CEO Blog: http://blog.ludovic.org/ XWiki: http://www.xwiki.com Skype: ldubost GTalk: ldubost

12 years, 5 months

2
4
0 0

Re: [xwiki-devs] How to add a user to a group programmatically?

by jordiduran

Hello, first I would like to say thank you for your reply, and tell you I use XEM 4.0. I use the code bellow to authorize a user and the same time to assign in a group, if he/she doesn't exist. The problems is when the code performs the assignment in a group, since you are not logged in, you are a XWikiGuest, the group page have to have explicit rights (edit) for the guest. /** * * @author jdurancal */ @Component public class LTIAuthServiceImpl extends XWikiAuthServiceImpl { @Override public Principal authenticate(String username, String password, XWikiContext context) throws XWikiException { XWikiServletRequest request = (XWikiServletRequest) context.getRequest(); if (!context.getAction().equalsIgnoreCase("logout")) { try { LTIEnvironment LTIEnvironment = new LTIEnvironment(request); if (LTIEnvironment.isAuthenticated()) { String usernameLTI = LTIEnvironment.getUserName(); if (usernameLTI.contains(":")) { usernameLTI = usernameLTI.split(":")[1]; } // get the group to assigna to the user. String group = LTIEnvironment.getParameter("custom_groups"); return syncUser(usernameLTI, group, context, LTIEnvironment.isInstructor()); } else { Exception lastException = LTIEnvironment.getLastException(); System.out.println("Error LTI authentication " + (lastException != null ? lastException.getMessage() : "")); } } catch (Exception ex) { System.out.println("Execption authentication " + ex); } } // Fallback on standard XWiki authentication return super.authenticate(username, password, context); } /** * Creates the user if he doesn't exist in the XWiki repository. User is assigned * to the default XWikiAllGroup * @param user * @param context * @throws com.xpn.xwiki.XWikiException */ protected Principal syncUser(String user, String groupName, XWikiContext context, boolean isInstructor) throws XWikiException { String xwikiUser = super.findUser(user, context); String wikiNameShow = context.getDatabase(); System.out.println("["+wikiNameShow+"] usernameLTI="+user+", GroupsLTI:"+groupName); if (xwikiUser == null) { System.out.println("["+wikiNameShow+"] LTI Create user: User " + user + " does not exist"); String wikiname = context.getWiki().clearName(user, true, true, context); context.getWiki().createEmptyUser(wikiname, "edit", context); System.out.println("["+wikiNameShow+"] LTI Create user: User " + user + " has been created"); xwikiUser = "XWiki."+user; // if the user is "instructor", assign admin rights except in speakapps wiki if (isInstructor && !context.getWiki().getName().equalsIgnoreCase("speakapps")) { try { this.addUserGroup(xwikiUser, user, "XWikiAdminGroup", context); }catch(Exception ex) { System.out.println("["+wikiNameShow+"] Execption adding admin user "+ex); } } } // És un group però no és l'administrador if (groupName != null && !groupName.equalsIgnoreCase("XWikiAdminGroup")) { try { this.addUserGroup(xwikiUser, user, groupName, context); }catch(Exception ex) { System.out.println("["+wikiNameShow+"] Execption adding user a \""+groupName+"\" group "+ex); } } return new SimplePrincipal(context.getDatabase() + ":" + xwikiUser); } private boolean addUserGroup(String xwikiUser, String user, String groupName, XWikiContext context) throws XWikiException { boolean isAdded = false; Group group = Group.getGroup("XWiki", groupName, context); if (group != null && !group.isMember(xwikiUser, context)) { if (group.addUser(user, context)) { group.save(context); isAdded = true; System.out.println("["+context.getDatabase()+"] add a \""+groupName+"\" member " + xwikiUser); } } return isAdded; } } Best regards. -- View this message in context: http://xwiki.475771.n2.nabble.com/How-to-add-a-user-to-a-group-programmatic… Sent from the XWiki- Dev mailing list archive at Nabble.com.

12 years, 5 months

1
0
0 0

[xwiki-devs] [ANN] XWiki 5.0 Milestone 2 released

by Thomas Mortagne

The XWiki development team is proud to announce the availability of XWiki 5.0 Milestone 2. This release introduces some important changes like the new security module by default, XWiki is now always in virtual mode, JQuery is embedded by default, xwiki/1.0 syntax is now disabled and lots of other improvements. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki50M2 Thanks -The XWiki dev team

12 years, 5 months

1
0
0 0

Re: [xwiki-devs] How to add a user to a group programmatically?

by jordiduran

Hi Adreas, I'm the same problem as you, have you got the solution? Thanks! -- View this message in context: http://xwiki.475771.n2.nabble.com/How-to-add-a-user-to-a-group-programmatic… Sent from the XWiki- Dev mailing list archive at Nabble.com.

12 years, 5 months

3
2
0 0

[xwiki-devs] [ANN] Test Reporting Application

by Sorin Burjan

Hello everybody, I have created a Test Reporting Application in order to make the Manual Testing Plan more easily to follow and execute. The rationale behind this is: * Hard to update a monolith page with all the manual tests performed * When someone who is testing is updating the page, no other user can update the page * It allows existing manual cases to be marked as automated (if we have an automated tests for them) * Easier to follow, track over what has been tested and what not Since I'd like to propose this to be used in the XWiki community for our Manual Test cases, I have put a live version on Incubator along with some test cases so I can get your suggestions before putting it in actual production/usage. I'm sure you will have some cool suggestions on how to improve it even further. So give it a try. I have also added a suggestions page linked form the application homepage. Note that the application was designed to be generic, so everybody can use it in their own software project. Contrib repo: https://github.com/xwiki-contrib/application-testreporting Incubator Live version: http://incubator.myxwiki.org/xwiki/bin/view/QA/WebHome Suggestions page: http://incubator.myxwiki.org/xwiki/bin/view/QA/Suggestions Looking forward to get your feedback ! Regards, Sorin B.

12 years, 5 months

5
6
0 0

[xwiki-devs] Two skins, one DB?

by Paul Libbrecht

Hello fellow developers, has anyone tried running two XWiki instances on the same DB? I think everyone doing clustering does this, with the addition of the observation module for emptying caches when appropriate. Has anyone tried running this same configuration (two servers simultaneously) but with two different URLs and two different skins? (but the same core)? It looks just as doable to me. Or? Thanks for hints. Paul

12 years, 5 months

3
4
0 0

[xwiki-devs] [Retrospective] Big slippage on all aspects for 5.0M2 - Chance to learn

by Vincent Massol

Hi devs, I'd just like to point out that 5.0M2 seems to be a very bad release WRT the roadmap we had defined, although a lot of hard work has been done. It's been a long time since we've diverged that much actually. Let's take this as a chance to learn and do a quick retrospective. Roadmap: http://www.xwiki.org/xwiki/bin/view/Roadmaps/WebHome Misses from Roadmap: * SOLR implementation missing the scheduler and thus cannot replace the default search. Main reason: Edy is sick currently. * AppWithinMinutes work * Scalable import/export * Home page improvements (XE) and usability improvements in general * Horizontal Menu management (add, remove pages) * XEM Homepage / Portal investigation * New Activity Stream Investigation Hits: * EM upgrade of subwikis. Mostly done but still missing a few things * virtual=1 by default * WYSIWYG Editor improvements * 60% of listed important bugs * General Flavours Investigation And WRT dates we're slipping by 10 to 15 days…. Other miss: the build stability. The whole build has been down for over 10 days and there are still failing modules. There has been a lot of stuff done of course but they were not planned (i.e not on the roadmap). This is our biggest miss and what I want to point out: we've not followed the defined roadmap and instead we've done other stuff like putting the new security module on by default which took us very long. We need to learn from what happened to handle it better next time and we now need to get back on track and go back to following our defined roadmap. IMO the following should have been done better (and that's what we should learn for next time): * Discuss replacing some items from the roadmap by others from the beginning. For ex don't take the task of setting the new security as the default without putting it in the roadmap * Setting the new security module should have been done on a branch and the tests/code fixed there before merging it on master. As a general rule nobody should commit anything on master knowing that it would break the build. Because that impacts everyone and prevents everyone from working on what they have to work on. * Similarly, if a commit is done and we realize afterwards that it breaks a lot of stuff, we should revert and put on a branch (I have the JUnit 4.11 upgrade in mind, which changed test order) * Removing xwiki/1.0 syntax by default with the breakage of several tests should also not have been committed directly without fixing the tests first, either locally or on a branch if we want to share the workload WDYT? Do we agree about handling it this way for next time? Since I wasn't there during most of this timeframe (holiday for 1 week and then conference for another week) I may have missed some other stuff an I may even be wrong about what happened. Please correct me or add what I missed. Thanks -Vincent

12 years, 5 months

1
0
0 0

Re: [xwiki-devs] [xwiki-notifications] xwiki-platform Quality Checks - Build # 210 - Failure!

by Sergiu Dumitriu

On 04/01/2013 03:20 PM, Jenkins wrote: > [WARNING] Insufficient code coverage for INSTRUCTION: 9.47% < 9.48% Happened again... -- Sergiu Dumitriu http://purl.org/net/sergiu

12 years, 5 months

1
0
0 0

[xwiki-devs] [VOTE] Use the new security-authorization module per default in XWiki 5.0

by Denis Gervalle

Hi devs, We have a new (component based) authorization module since a while now, and I think 5.0 is the perfect time to introduce it as the default right service. First, I simply propose to change the default in xwiki.cfg: xwiki.authentication.rightsclass=org.xwiki.security.authorization.internal.XWikiCachingRightService (Later, I propose that we deprecate that bridge and that we create a friendly (xwiki oriented) interface over the more generic org.xwiki.security.authorization.AuthorizationManager. But leave this for a later proposal.) So this vote is about changing the default in xwiki.cfg before 5.0M2. pros: - improved performance, since the new service is using caching techniques and a single page load required lots of calls to it. - ability for extension to add new rights - define right declaratively - separate method for checking and verifying right (throws opposed to boolean return) - fix some long waiting bugs like XWIKI-5174, XWIKI-6987, as well as some unstated ones - possibility to easily solve issues like XWIKI-4491 - no more admin right per default - being in good position to improve it and release dependencies to oldcore for security matters. - possibility for third party to adapt the right settler to their special needs (right decision is plugable) - a consistant right evaluation with very few exception that could be explained and documented cons: - no more admin right per default, but since we have DW, the initial setup is no more a problem, and advanced users may use superadmin. - groups are only checked from the user wiki, not from the accessed entity wiki. - may exhibit some other minor differences compare to existing implementation (but mostly consistency fixes) - test could be improved, critical part (right, settler, data structure, cache) are covered at almost 100%, api at 60%, this is probably better than the old right service - documentation should be improved, but this is not worse than the old one anyway Since I use the new module in all my production servers for several months with success, and I really think that if we do not do it now we will never go ahead, here is my big +1 WDYT ? -- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO

12 years, 5 months

9
28
0 0

[xwiki-devs] [Idea] Add similar issue feature to our JIRA

by Vincent Massol

Hi guys, I'd like to add the "similar issues" features of http://www.plugenta.com/suggestimate/jira/tour.html You can see it in action at https://jira.exoplatform.org/browse/CRASH-114 for example. I've asked plugenta for a free open source license. Hope this is fine with you all. Let me know if you have any issue with this. Thanks -Vincent

12 years, 5 months

2
2
0 0

[xwiki-devs] [VOTE] Retire the old WYSIWYG editor

by Sergiu Dumitriu

Hi devs, Related to the other vote about disabling the xwiki/1.0 syntax [1], I'd like to retire the old WYSIWYG editor. Although there aren't any obvious benefits, on the contrary it, removes an important feature, the advantages for doing this are: - fewer bugs (there are known bugs that we've decided not to fix since we agreed not to maintain it anymore) - less code (the .vm templates that support the editor are really crappy and I'd be very happy to get rid of them completely) - strongly encourages (developer) users to migrate to the new syntax - less non-valid, non-accessible code (standards compliance) - fewer places where XSS holes can hide (security) Personally I'd like to remove it completely, but there's also the option of putting it in a -legacy- module, still enabled in the final releases. This makes two options: A) Move the editor in a xwiki-contrib retired module B) Move the editor in xwiki-platform-legacy-web and leave it enabled My +1 goes for A. [1] http://xwiki.markmail.org/thread/6damxrncgohtk4oc -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 5 months

5
4
0 0

[xwiki-devs] [VOTE] Disable (hide) the xwiki/1.0 syntax

by Sergiu Dumitriu

Hi devs, It's been a (long) while since the introduction of the xwiki/2.0 syntax and the new rendering engine (introduced in 1.5, declared "usable" in 1.8, set as default in 1.9). This means that since ~2008, most of the development and maintenance effort has gone into the new rendering engine and the new WYSIWYG, and this left the xwiki/1.0 syntax and old WYSIWYG editor mostly unmaintained. All the platform and XE documents have been migrated away, but there are still XEM documents using the old syntax. I'm proposing to hide the xwiki/1.0 syntax by default, so that it's no longer easy to create a new document in that syntax (unless a template is used) or to select it as the new syntax for an existing document. It will continue to be available for existing documents. +1 from me. (I guess the 72h rule won't be applied since the next 72 hours are holidays for lots of developers) -- Sergiu Dumitriu http://purl.org/net/sergiu/

12 years, 5 months

7
6
0 0

[xwiki-devs] dates for revisions was updated to the date of updates

by Добровольский Евгений

Hi! I have next issue: After xwiki update from 3.2 to 4.5 all dates for revisions was updated to the date of updates. How can i fix it? I see only one way to change it in the DB: update xwikircs set xwr_date= FROM_UNIXTIME(CONVERT(substr(xwr_patch,locate('<date>', xwr_patch)+6,13),UNSIGNED INTEGER)/1000) commit is it correct? will it have impact on other objects ( keys, indexes)? mayby someone has other ideas how to fix it ..

12 years, 5 months

3
4
0 0

[xwiki-devs] [BRAINSTORM] You're rewriting XWiki, you can use any technology in the world, describe it.

by Caleb James DeLisle

This is the premise, you are going to write a new XWiki. You are not bound by any backward compatibility requirements. Use any technology or combination of technologies. PHP? C++? Golang? Node.js? Java? Your call! Describe it in as much detail as possible. What frameworks will you use? What ORM? what databases? Why will it perform well? How will you get new features into the hands of users quickly? How will you avoid this: http://steve-yegge.blogspot.ca/2007/12/codes-worst-enemy.html and this: http://www.laputan.org/mud/ Think big and go wild! Thanks, Caleb

12 years, 5 months

5
9
0 0

[xwiki-devs] MyPersistentLoginManager.checkValidation

by Paul Libbrecht

Hello fellow developers, So as to preserve security of our users, we do one small thing: the user-name and password (and registration info) is submitted over https. All other communication is done over http. This works well for someone connected normally to the internet. This works incorrectly for someone who is forced to use a proxy by its network conditions, e.g. hotels, wifi hotspots and mobile devices' provided networks. The reason it is the case, it the following MyPersistentLoginManager.checkValidation checks a "validation" cookie which computes a salted hash of the triple username, password, and IP. And in the cases above, the IPs are different, so the validation fails, the login is unsuccessful, the console says: > Login cookie validation hash mismatch! Cookies have been tampered with What our options? Is it true that removing IP in this validation would make the system weak as anyone stealing the cookie from another IP could become that user? Would it be as simple as finding the right header "chain end" and replace it? It seems that it would be possible. paul

12 years, 5 months

2
3
0 0

[xwiki-devs] [ANN] XWiki 4.5.3 released

by Marius Dumitru Florea

The XWiki development team is proud to announce the availability of XWiki 4.5.3. This is a bugfix release. You can download it here: http://www.xwiki.org/xwiki/bin/view/Main/Download Make sure to review the release notes: http://www.xwiki.org/xwiki/bin/view/ReleaseNotes/ReleaseNotesXWiki453 Thanks -The XWiki dev team

12 years, 5 months

1
0
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