xwiki-devs March 2010

xwiki-devs@xwiki.org

45 participants
125 discussions

[xwiki-devs] [VOTE] Release XE 2.3 Milestone 1

by Jean-Vincent Drean

Hi, Since it is now stable, I'd like to release XE 2.3 Milestone 1 tomorrow morning. Here's my +1. ps: there's one last functional test failing which will be fixed in a few minutes. Thanks. JV.

14 years, 9 months

[xwiki-devs] [Proposal] Add APIs to get and save document in the security context of the author of the script which called the function.

by Caleb James DeLisle

I'd like to make this change: Add to xwiki.api.Document saveAsAuthor() saveAsAuthor(String comment) saveAsAuthor(String connent, String isMinorEdit) deleteAsAuthor() Add to xwiki.api.XWiki getDocumentAsAuthor(DocumentReference reference) getDocumentAsAuthor(String fullName) I created an issue for it and posted a patch http://jira.xwiki.org/jira/browse/XWIKI-5041 http://jira.xwiki.org/jira/secure/attachment/16920/XWIKI-4952-CommentAddAct… The context user is momentarily switched to the content author of the document in the context before doing the action. I think the script editor should be responsible for the api method calls because they can only be called from script. I also see a lot of potential benefit in allowing a script to manipulate documents which it's viewers cannot save. I think this will reduce the amount of pages requiring programming rights. WDYT? Caleb

14 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r27821 - platform/core/branches/xwiki-core-2.2/xwiki-rendering/xwiki-rendering-api

by Sergiu Dumitriu

On 03/23/2010 04:36 PM, tmortagne (SVN) wrote: > Author: tmortagne > Date: 2010-03-23 16:36:20 +0100 (Tue, 23 Mar 2010) > New Revision: 27821 > > Modified: > platform/core/branches/xwiki-core-2.2/xwiki-rendering/xwiki-rendering-api/pom.xml > Log: > XWIKI-4984: Header ids are always the same ("H") with Chinese or any other language without any ASCII character. > * missing direct dependency > > Modified: platform/core/branches/xwiki-core-2.2/xwiki-rendering/xwiki-rendering-api/pom.xml > =================================================================== > --- platform/core/branches/xwiki-core-2.2/xwiki-rendering/xwiki-rendering-api/pom.xml 2010-03-23 15:35:43 UTC (rev 27820) > +++ platform/core/branches/xwiki-core-2.2/xwiki-rendering/xwiki-rendering-api/pom.xml 2010-03-23 15:36:20 UTC (rev 27821) > @@ -39,6 +39,11 @@ > <artifactId>commons-lang</artifactId> > </dependency> > <dependency> > +<groupId>commons-httpclient</groupId> > +<artifactId>commons-httpclient</artifactId> The version is not needed, it's defined in the root pom. Not specifying it here will make it easier to upgrade in the future. > +<version>3.1</version> > +</dependency> > +<dependency> > <groupId>org.xwiki.platform</groupId> > <artifactId>xwiki-core-xml</artifactId> > <version>${pom.version}</version> -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 9 months

[xwiki-devs] [Vote] Use scpexe instead of scp for maven deployments

by Florin Ciubotaru

Hi, We're now setting up the windows build agent for hudson. In order to make deployments from windows machines we need to switch the protocol from scp to scpexe. The local machines needs to declare the ssh and scp tools configuration in maven's settings.xml. Windows tools like putty and pscp are not properly configured when the protocol is set to scp. The deployment protocol is specified in our parrent pom. Eg: <distributionManagement> <site> <id>maven.xwiki.org</id> <url>scp://maven.xwiki.org/home/maven/public_html/site</url> </site> <repository> <id>maven.xwiki.org</id> <name>XWiki Maven2 Remote Repository for Releases</name> <url>scp://maven.xwiki.org/home/maven/public_html/releases</url> </repository> <snapshotRepository> <id>maven.xwiki.org</id> <name>XWiki Maven2 Development Repository for Snapshots</name> <url>scp://maven.xwiki.org/home/maven/public_html/snapshots</url> </snapshotRepository> </distributionManagement> WDYT about changing this? Thanks, Florin Ciubotaru

14 years, 9 months

Re: [xwiki-devs] [xwiki-notifications] r27798 - platform/web/trunk/standard/src/main/webapp/resources/uicomponents/widgets/validation

by Sergiu Dumitriu

On 03/23/2010 05:19 AM, cjdelisle (SVN) wrote: > Author: cjdelisle > Date: 2010-03-23 05:19:38 +0100 (Tue, 23 Mar 2010) > New Revision: 27798 > > Modified: > platform/web/trunk/standard/src/main/webapp/resources/uicomponents/widgets/validation/livevalidation.css > Log: > XWIKI-5038: With Toucan skin, LiveValidation borders cause text below a field to shift when field is clicked on. - Removed field borders from stylesheet. This change means that upgrading to a future version will be harder. So, the question is: Do we override the style in our own skins, causing bigger files, but keeping it simple to upgrade in the future, or do we fully adopt LiveValidation and hack it as much as we want, improving it even further? Personally I vote for the second. > > Modified: platform/web/trunk/standard/src/main/webapp/resources/uicomponents/widgets/validation/livevalidation.css > =================================================================== > --- platform/web/trunk/standard/src/main/webapp/resources/uicomponents/widgets/validation/livevalidation.css 2010-03-23 00:30:42 UTC (rev 27797) > +++ platform/web/trunk/standard/src/main/webapp/resources/uicomponents/widgets/validation/livevalidation.css 2010-03-23 04:19:38 UTC (rev 27798) > @@ -10,20 +10,4 @@ > .LV_invalid { > color:#CC0000; > } > - > -.LV_valid_field, > -input.LV_valid_field:hover, > -input.LV_valid_field:active, > -textarea.LV_valid_field:hover, > -textarea.LV_valid_field:active { > - border: 1px solid #00CC00; > -} > - > -.LV_invalid_field, > -input.LV_invalid_field:hover, > -input.LV_invalid_field:active, > -textarea.LV_invalid_field:hover, > -textarea.LV_invalid_field:active { > - border: 1px solid #CC0000; > -} > -- Sergiu Dumitriu http://purl.org/net/sergiu/

14 years, 9 months

[xwiki-devs] [Proposal] Add api to allow scripts choose with the permission of their author.

by Caleb James DeLisle

Right now a script which is saved with programming access is allowed to do things which the viewer (who executes it) is not allowed to do. I would like to extend this to scripts which do not have programming access. Use case example: A page where the viewer can submit an email address to be put on a mailing list. The page needs to be able to save the email address to a list but the viewer should not be able to directly edit (or view) the list. I would like to add to xwiki.api.Context: void setScriptUser(String) String getScriptUser() (These names are the best I could think of, suggestions would be great) the input can be either "viewer", "author" or "default" and it stores this in the XWikiContext If the value is set to author, hasAccessLevel will return an access check on the author, not the viewer. When includeForm is called, or the include macro is invoked, the only explicit change is that changes made by the called document will be reset when the include ends. If scrips are set to run with author's permissions: If DocumentA includes documentB, documentB executes with documentB's author's permissions. If DocumentA includes _in context_ documentB, documentB executes with documentA's author's permissions. When include of documentB ends, scriptUser is set back to the value which documentA left it at. I think this will help us achieve the goal of no documents with programming rights in the XE xar file. WDYT? Caleb

14 years, 9 months

[xwiki-devs] Don't want the TODO Class and its clone share data entries

by jackyork

I have Todo class installed. The Todo class is downloaded from xwiki.org. By default it is shared by everyone. Now our department wants a public TODO for everyone and a "private" TODO for each group at our department. I cloned the TODO class to in every space. But I found if I input an entry in SpaceA.Todo, all other SpaceX.Todo show this entry. How to keep the entry in SpaceA.Todo only and not to share it among all clones? -- View this message in context: http://n2.nabble.com/Don-t-want-the-TODO-Class-and-its-clone-share-data-ent… Sent from the XWiki- Dev mailing list archive at Nabble.com.

14 years, 9 months

[xwiki-devs] PropertyClass questions

by Hugh Hulme

Hi, me again :) Firstly, thank you for your help so far - it is hugely appreciated. On to the question: I searched xwiki.org for PropertyClass and found only release notes. I'm looking for a way to determine if a value has been entered into a text field, so that I can omit the entire section from the sheet if it's empty. First I guessed that there would be a length() property on a string, but was unsuccessful. Then I guessed from the VTL Reference & User Guide that I might be able to use size(), if a string was actually a char[], but was disappointed. Any clues? Thanks again, - Hugh

14 years, 9 months

Re: [xwiki-devs] [foaf-protocols] DNSSEC update and client side certificates

by Story Henry

Thanks a lot Dan for the feedback. It is very helpful for us to understand where things are going on the DNS front, as this is a core technology we are building on. Here is how I see the DNSSEC and the foaf+ssl stories converging. DNSSEC solves the DNS security problem in a delegated fashion. As you say it is a bootstrapper. As it is deployed the trust we can have in domain names, and hence in URLs will grow dramatically. Not only will we be sure that we are talking to the right machine (ip address to be correct), but it will be easier for people to deploy secure endpoints such as https. Foaf+SSL builds on that to create a web of trust for agents. It is worth considering the difference between foaf+ssl and PGP, since you mention it below. PGP ties the identifier (an email address usually) to a public key. There is not 1 PGP keyserver: there are many. These need to be synchronised somehow, and can easily get out of date. If you feel like your private key has fallen in the wrong hands, you need to notify all key servers. Furthermore your PGP web of trust is completely public. People can 20 years later look at the relations of who signed whose key to determine who knew whom. And there is no way of removing a relationship. FOAF+SSL on the other hand ties a public key to a WebId (a URL), which is tied to a machine via DNS and soon DNSSEC. The key server is the web, which is based on the internet, which is based on DNS. So we get all the good properties of DNS. If your private key is compromised, you just need to update the information at your WebId, and remove the public key information there. Updating the foaf+ssl key server is as easy as updating a web page - and this is even more true now that the RDFa spec has been blessed by the W3C. So one of my WebIds is http://bblfish.net/#hjs, which tied to a web page. Secondly you can protect who can see the relations in your web of trust. You could allow only friends to have access to your friend relations using HTTP access control. If you discover that someone you thought was trustworthy no longer is, you can just remove them from your Foaf profile. Again that is as simple as editing a web page. (try hunting down all the people whose PGP profile you signed :-) So FOAF+SSL gives us a web of trust but built on the most powerful naming system (key server) in existence: the web. The web is built on DNS, which is has 25 years of successful delegation, and with DNSSEC will give us another century :-) Even better foaf+ssl uses X.509 which thanks to your work is going to end up being secure. Even better we don't rely on the CA signing part of X.509 which was used to 'secure' servers, and so we don't suffer from the race to the bottom you describe so well in your talks. In any case CA's never really attempted to certify people. That would have been practically and legally infeasible. So it seems to me that FOAF+SSL and DNSSEC are perfectly complementary. Of course we still have to prove our case, and we have work to do building a lot more cool demos to show how it can work... This is what we are buisy doing now. Thanks again for your very helpful feedback. Sincerely, Henry Story On 20 Mar 2010, at 23:17, Dan Kaminsky wrote: > My critiques against X.509 come down to the fact that it's just not a > very good way to delegate trust. The roots are all equal and the > constraints don't work reliably. > > DNS has 25 years of successful delegation. It has one root and it's > constraint system is very well designed. DNSSEC simply inherits this, > and adds crypto. > > There is a significant question for DNSSEC, which is what do we put in > DNS now that we have a way to bootstrap trust? > > Certs? > Cert fingerprints? > Public keys? > Public key fingerprints? > > There are arguments for each. I'm leaning towards cert fingerprints > right now, but haven't entirely decided. DNS is not a high bandwidth > channel, it's a bootstrapper. So that's a constraint. Keeping > appcompat with existing X.509 architectures -- making DNSSEC an > exclusionary 'uber-root' -- has serious value too. > > One thing I should make clear is I see value to the CA's. > Specifically, EV is the only way I see to overlay a closed, branded > namespace on top of DNS. This is a big deal. > > The thing I want to make clear is that I am not a big fan of > distributed trust systems. I tend to see them unable to scale. I am > however even less a fan of tightly centralized trust systems. The > central provider doesn't even need to be malicious, just overburdened. > PGP doesn't work, not with web of trust and not with keyservers whose > records are constantly getting out of date. > > Delegation works well, but only if the root of the delegation is > trustworthy. Well, the corollary to so many things breaking if DNS is > hacked, is that we really, really invest a lot of trust in the root > already. You guys know the old quote, a CA is only as strong as the > money it refuses to take? > > The root, as an element of be state system, is an element of the > system that makes money itself. It's bureaucratic as all get out and > this is not a bug, but a feature. Its intransigence is a useful > defensive bulwark with no peer. > > > > > On Mar 20, 2010, at 2:44 PM, Henry Story <henry.story(a)gmail.com> wrote: > >> Hi, >> >> Here are two issues with X509 that were hindrances for a solution >> like foaf+ssl to be deployed, but which can and are being fixed: >> >> 1. Client Side Certificate selection >> ------------------------------------ >> >> Browsers currently do a very bad job of allowing the user to choose >> his certificate (Safari being the absolute worse). As a result I >> posted "Firefox Hackers Needed" >> >> http://bit.ly/cQ5f48 >> >> earlier this week. @snej who is working at Google put up a picture >> of a solution for this in Chrome using a foaf+ssl certificate >> created by http://webid.myxwiki.org/ >> >> http://bit.ly/azCXTU >> >> Vote for it! >> >> 2. Server side certificates >> --------------------------- >> >> One factor that people mention often with foaf+ssl is that the >> server has to have his own certificate. This means registration with >> a CA which is costly and tedious and it does not really solve the >> problems of server authentication as Dan Kaminsky shows ruthlessly >> in "Black Ops of PKI" http://bit.ly/4Uwb2K . >> >> To summarise his talk, server security is in a double bind: >> >> 1- Dan Kaminsky's DNS poisoning attack which is very well explained >> by Rick Van Rein's presentation "Cracking Internet: the urgency of >> DNSSEC" ( http://bit.ly/2darr8 view with FFox > 3.5 as it uses ogg >> video) means that a DNS easily be hacked in 6 weeks, and a lot of >> money poured into the wrong people's pockets. So there is a >> financial incentive to break DNS. >> >> 2. The solution of using https with X.509 public key cryptography's >> backing cannot work because there is a race to the bottom in the way >> CA's issue certificates. For enough money it is not that difficult >> to become God and to pretend you are anyone. >> >> Given the above DNSsec has become urgent enough, that it is being >> deployed. >> >> - verisign will put .com in July http://bit.ly/dyd54E >> - .org will be available in June http://bit.ly/abEJ28 >> - .gov went dnssec in March 2009 http://bit.ly/bH27b0 >> - The root will be signed July 2010 http://bit.ly/9YQMDJ >> - a map of dnssec deployment http://www.xelerance.com/dnssec/ >> >> So listening to Dan Kaminsky you would think that he is against >> X509. Well certainly it could be improved a lot, but he is not quite >> as negative as one may think. X.509 with DNSsec seems to be >> something he thinks can work. >> >> What he told me after his CCC and HAR talks and what you can see in >> the last few minutes of the HAR talk "X509 considered Harmful" http://bit.ly/2darr8 >> is that once DNS is secure one could put the X509 (self signed >> even) certs into the DNS records. This would bypass the need for >> CAs. [ I hope I understood him correctly ]. I am not sure what needs >> to be done to make this possible with the browser vendors, but it >> would massively improve security on the web. >> >> As a result I have fait that the global situation on the internet >> will only make foaf+ssl solutions easier and more secure to deploy, >> enabling a completely distributed social network to emerge, free and >> without the spying, as Eben Moglen author of the GPL said so well >> recently http://bit.ly/brQmJz >> >> Henry >> >> >> Social Web Architect >> http://bblfish.net/

14 years, 9 months

[xwiki-devs] XE 2.3M1 release preparation

by Vincent Massol

Hi, We've slipped badly for the 2.3M1 release (my fault for not monitoring it closely enough). It was planned on the 8th of March and we're the 15th already (one week delay). The other problem is that we don't have what we had imagined would go in 2.3M1 (color theme improvement for ex). Right now there are lots of changes but nothing really user-noticeable. So I'd suggest the following: * Delay by a few days in order to be able to include: - color theme improvement. Sergiu you need to tell us if that's doable and for when. - captcha on comments. Caleb, let us know if that's all done or if there's need for more testing/development. Bonus: - Anca, will it be possible to have annotations released for 2.3M1 (ie now)? How much more time would you need? Thanks -Vincent

14 years, 9 months

← Newer
1
2
3
4
5
6
7
8
...
13
Older →

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

2005

xwiki-devs March 2010