Hi Edo, I hope that my comments below will not fall too hard since they arrive after the fact. So, first, I would like to congratulate you for your participation. On Tue, Jul 30, 2013 at 6:50 PM, Edoardo Beutler < [email protected]> wrote:
Hi Vincent and devs
Sorry for the delay, but getting to know the new Authentication and how we can change it got a bit out of hand ;-)
You should have asked during the hackathon, it is also a event to team together, and I would have been more than happy to help you understanding the new security authorization module. I have quickly review your implementation, and it have for sure require a deep understanding of the current implementation. This is also what will make your extension more fragile, since it really depends on implementation details that may change over time. I noticed that you have taken care of checking these details to fail gracefully which is nice. We decided to prepare the publication extension for xwiki 5.1. It worked
(in our old 2.7.2) by extending the XWikiRightServiceImpl and changing the rights accordingly. Now - due to the caching - this is not so easy anymore,
For sure, right caching is not that easy, and it implies a bit of complexity, especially if you expected some access to change simply based of the elapsed time since the decision has been taken.
so I wanted to give you some feedback on where and why we struggled: - We did not want to replace the whole AuthorizationSettler, but just to extend the default implementation. To do so we needed a possibility to change the SecurityAccessEntry we got back from the default impl. The problem was, that all the setters (set, deny, allow) in XWikiSecurityAccess are package private. As far as we understood, the only possible way to do this, is to put our class in the package org.xwiki.security.authorization.internal.
Well, this is true. Maybe I got a bit paranoid on this, but my feeling was that the settler should be the only one with the power of creating and changing a SecurityAccessEntry. This obviously make it difficult for a class from another package to simply extends the existing implementation.
- To get it to work with the caching we had to extend the DefaultAuthorizationManager but we found no easy way to get the date when a cache entry was created, which we would have needed.
I understand why you would like to have a date from the security cache, this is clever idea even if it has not been made for that. Adding the date should not be complex since the cache store SecurityEntries and those are generated by the AuthorizationSettler. But I am afraid that using those dates later is more complex without somewhat "hacking" the AuthorizationManager. Extending the AuthorizationManager is risky. Evicting entries from other places than the SecurityCacheRulesInvalidator is probably a bad idea and could lead to multithreading issues. Moreover, if I have correctly understand your current implementation, it defeat completely the caching of access entries, which is bad for the performance of the security module. At least, you should mention that in the description of your extension, so nobody get surprised. The best alternative I can think about right now, is to extend the SecurityCacheRulesInvalidator in a way that cause entries to be evicted from the cache in due time, when those became invalid. You may for example keep a cached list of cached entries in your own independent cache with their associated publish times. Listening to the security cache events, you may keep that list clean and up to date. Based on that list, it should be possible to program some timer to trigger an extended SecurityCacheRulesInvalidator at appropriate time. Let me know if you would like to discuss that subject further and I will do my best to help. Thanks again for your participation.
As also linked on the Hackaton page you can finde the extension on http://extensions.xwiki.org/xwiki/bin/view/Extension/PublishUnpublish
Thanks, Edo
On Wed, Jul 24, 2013 at 12:33 PM, Vincent Massol <[email protected]> wrote:
Today is the last day of the Hackathon!
Please update the http://dev.xwiki.org/xwiki/bin/view/Hackathon2013/WebHome page with your hackathon details and the status.
What is ideal is to be able to publish the results of your hackathon somewhere so that it's visible to others. A good place is http://extensions.xwiki.org
I'll blog a summary about it next week.
Thanks to all who participated! :) -Vincent
On Jul 15, 2013, at 11:10 PM, Vincent Massol <[email protected]> wrote:
I've created the hackathon 2013 page at http://dev.xwiki.org/xwiki/bin/view/Hackathon2013/WebHome
You can start pushing ideas there :)
Thanks -Vincent
On Jul 15, 2013, at 12:14 PM, Vincent Massol <[email protected]> wrote:
Hi devs and community at large,
Every year XWiki SAS (http://xwiki.com) gathers all its employees for a Seminar and every year we have an internal hackathon.
For example here are the results of last year: - 2012: http://www.xwiki.com/lang/en/Company/Hackathon2012 - 2011: http://www.xwiki.com/xwiki/bin/view/Company/Hackathon2011
This year the Hackathon will run for 10 days!
Thus we thought it could be a good idea to invite the XWiki Community to join us for a mega distributed Hackathon!
So here's how I think we could organize it:
* Start date: 17th of July. A mail will be posted on this day to announce the start * End date: 25th of July. A mail will be posted on this day to announce the end * Gathering results: from 29 to 6th of August. Everyone who participated should reply to the end of hackathon mail with what they did and post their stuff on http://extensions.xwiki.org or elsewhere * On around the 6th of August we'll have a blog post written on xwiki.org summarizing all that was done by everyone
Those who have participated will also get XWiki T-Shirts.
Anyone interested in joining the fun?
Thanks -Vincent with my XWiki SAS employee hat
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
_______________________________________________ devs mailing list [email protected] http://lists.xwiki.org/mailman/listinfo/devs
-- Denis Gervalle SOFTEC sa - CEO eGuilde sarl - CTO