Hello,
We continue to do our homeworks concerning a project we have to build a wiki for our enterprise: 80 000 employees, but only 1000 of them could have access to the wiki: usually in read, some people in read/write. We will need per namespace security: some namespaces should not be read by some groups We dont want to go with many tons of wikis installation
I wrote a post on another mailing list about it a couple of days ago: http://www.gossamer-threads.com/lists/wiki/mediawiki/381274
I had some very good and helpful comments, but its after that I found another mailing list (this one), which seems dedicated to the enterprise usage of Mediaiwki.
Here are the requierement we have:
Main page
- NamespaceA (read for departmentA only)
- NamespaceB (read for departmentB only)
- .
- NamespaceZ (read for departmentZ)
Sometimes, someone of departmentA will need read access to NamespaceZ, etc
I would like to have some testimonials: your experiences, your recommendations on a specific aspect of Mediawiki: ACL !!! (recurring topic, I believe ).
I read http://blog.blue-spice.org/2012/10/23/mediawiki-vs-confluence-not-a-question -of-features/ and found that they use Lockdown and some other extensions around it, to secure the wiki
As everyone, I read http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions and http://www.mediawiki.org/wiki/Category:Page_specific_user_rights_extensions
So, I wrote to BlueSpice team to know if they believe that Lockdown is really secure to write sensitive data in a Mediawiki wiki. Answer was honest: no (as expected).
I wrote also to the guy who founded Intelpedia (Josh Bancroft) and he confirms that Mediawiki is the wrong tool to manage that kind of ACL and that they use other tools for sensitive data, not their wiki I didnt insist to know which other tool I was impressed that a guy at this level take the time to answer me, so J
Anyway, could you tell me what is the kind of setup you have on this side (ACL) ? Certainly that some of you use in the facts an ACL extension (Lockdown or others) ? Do you trust them ? Do you have implement some other kind of security ? etc Wikifarm ? etc
Sincerely, I believe I have read enough on the web about the subject now, I need some concrete experiences, from real persons, in real enterprises,
Voilà.
Thanks !
Pierre
I guess that one option for you will be to hire somebody or some company for developing Lockdown further so that they can cover all the holes from which the information can bet got. HalloWelt itself is a perfect candidate and we also have a lot more developers available [1]. Probably you will also want to hire different contractor that will try to steal the data from the modified extension.
Of course, after some time the extension will stop working because of ugly hacks that will definetely appear in the code.
Another and more proper solution is not so fast, that is: to lobby the proper ACL support in MediaWiki core before starting development. MediaWiki is used as an enterprise wiki and the impossibility of good ACL should not be considered as not some kind of philosophy of the software (as some people claims) but as a bug that needs fixing. Still even in this case the actual development of ACL won't be done by WMF - they aren't just interested in it. But if we would have carte blanche for patching the core and not been declined because "MW is an Open System, it has not been Designed to allow ACL support", I think many parties will be interested to fund the development.
[1] www.mediawiki.org/wiki/Professional_development_and_consulting ----- Yury Katkov, WikiVote
On Sat, Aug 24, 2013 at 1:36 AM, Pierre Labrecque pierre.labrecque@live.ca wrote:
Hello,
We continue to do our homeworks concerning a project we have to build a wiki for our enterprise: 80 000 employees, but only 1000 of them could have access to the wiki: usually in read, some people in read/write. We will need per namespace security: some namespaces should not be read by some groups… We don’t want to go with many tons of wikis installation…
I wrote a post on another mailing list about it a couple of days ago: http://www.gossamer-threads.com/lists/wiki/mediawiki/381274
I had some very good and helpful comments, but it’s after that I found another mailing list (this one), which seems dedicated to the enterprise usage of Mediaiwki.
Here are the requierement we have:
Main page
NamespaceA (read for departmentA only)NamespaceB (read for departmentB only)….NamespaceZ (read for departmentZ)Sometimes, someone of departmentA will need read access to NamespaceZ, etc…
I would like to have some testimonials: your experiences, your recommendations… on a specific aspect of Mediawiki: ACL !!! (recurring topic, I believe…).
I read http://blog.blue-spice.org/2012/10/23/mediawiki-vs-confluence-not-a-question... and found that they use Lockdown and some other extensions around it, to secure the wiki
As everyone, I read http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions and http://www.mediawiki.org/wiki/Category:Page_specific_user_rights_extensions
So, I wrote to BlueSpice team to know if they believe that Lockdown is really secure to write sensitive data in a Mediawiki wiki. Answer was honest: no (as expected).
I wrote also to the guy who founded Intelpedia (Josh Bancroft) and he confirms that Mediawiki is the wrong tool to manage that kind of ACL and that they use other tools for sensitive data, not their wiki… I didn’t insist to know which other tool… I was impressed that a guy at this level take the time to answer me, so… J
Anyway, could you tell me what is the kind of setup you have on this side (ACL) ? Certainly that some of you use in the facts an ACL extension (Lockdown or others) ? Do you trust them ? Do you have implement some other kind of security ? etc… Wikifarm ? etc…
Sincerely, I believe I have read enough on the web about the subject… now, I need some concrete experiences, from real persons, in real enterprises,…
Voilà.
Thanks !
Pierre
Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
So, do we have to conclude that Mediawiki isn't a good choice for an enterprise (with these requierements) ??? I can't say to our management: "hey ! pay for a developer to patch Lockdown and the core...and in a couple of months/years, the hole system may fail after an upgrade of MW..." (caricature). :-)
The context: 1- many customers: for each customers, we have many teams to support them. Each of these teams needs a "secure space" for its documents. 2- of course, all these teams (dedicated to different customers) share some general documents. We don't need or want to secure everything: a lot of stuff can be shared by everyone.
Here is the design we try to explore actually: 1- create a shared wiki (in our office) 2- create a single wiki, on the network of a customer (so if 100 customers, it means 100 wikis: one per customer, each one on the customer network)
As it doesn't make sense for us that an employee of customer X visits the shared wiki to have access to general documents, then visits its own wiki (on the customer network) to access restricted stuff, we though to put in place a system where the admin of the customer wiki access the shared wiki and pulls some interesting info from the shared to the customer wiki. It has its limits... just a possibility...
So let's say it's a good idea... it means that the customer wiki will be accessible by all our employees dedicated to this customer... but in this wiki, there are many documents too, that we need to secure too. So:
1- Shared Wiki: (accessible by all admin of customer wikis, these admin pull info from it to put general stuff in their own wiki) 2- Customers Wikis (accessible by our people, located on the customers facilities) 3- Customers Wikis: accessible by each of our employees, dedicated to this customers. So if Jack and Daniel work for CompanyA, it means that both will log into the CompanyA wiki. 4- Customers Wikis: Jack and Daniel have different roles. Jack is a computer technician and must have access to general software procedures. Daniel works with servers and is specialized in the firewall configuration of this customer... Jack should not see the stuff of Daniel, right ? We believe that this info is sensitive... So it means that we need to secure some namespace (for example) to prevent Jack to access Daniel stuff... So LockDown extension ? 5- Security: here, if MW with Lockdown fails, it will be a failure which will stay on the customer network (damage is limited, but absolutely not desirable!!!). That's one of the reason we prefer to separate general stuff (shared wiki) from the customer wiki (sensitive): isolation of the failure. If we put Lockdown on a single wiki, shared by all, and that a failure occurs: it means that every customer may be able to access the data of everyone else (firewall config for example...).
That's where we are for now... Yes: Dokuwiki, MoinMoin, etc... have ACL and are cerftainly the best choice for medium size wikis. But what's append with these wiki engines when you have 200/300/400 000 - 1 000 000 pages ? Are they seriously designed to support all these pages/images/doc, etc ? The search feature will become slow ? etc... we don't know... And no money for paid wikis (Confluence and cie).
What else: there are a tons of wiki engines. Why we prefer to have Mediawiki ? Well... to be honest... it's Mediawiki :-)
I sincerely hope that my English is clear... :-)
Cheers !
-----Original Message----- From: mediawiki-enterprise-bounces@lists.wikimedia.org [mailto:mediawiki-enterprise-bounces@lists.wikimedia.org] On Behalf Of Yury Katkov Sent: Friday, August 23, 2013 6:32 PM To: MediaWiki for enterprises Subject: Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?
I guess that one option for you will be to hire somebody or some company for developing Lockdown further so that they can cover all the holes from which the information can bet got. HalloWelt itself is a perfect candidate and we also have a lot more developers available [1]. Probably you will also want to hire different contractor that will try to steal the data from the modified extension.
Of course, after some time the extension will stop working because of ugly hacks that will definetely appear in the code.
Another and more proper solution is not so fast, that is: to lobby the proper ACL support in MediaWiki core before starting development. MediaWiki is used as an enterprise wiki and the impossibility of good ACL should not be considered as not some kind of philosophy of the software (as some people claims) but as a bug that needs fixing. Still even in this case the actual development of ACL won't be done by WMF - they aren't just interested in it. But if we would have carte blanche for patching the core and not been declined because "MW is an Open System, it has not been Designed to allow ACL support", I think many parties will be interested to fund the development.
[1] www.mediawiki.org/wiki/Professional_development_and_consulting ----- Yury Katkov, WikiVote
On Sat, Aug 24, 2013 at 1:36 AM, Pierre Labrecque pierre.labrecque@live.ca wrote:
Hello,
We continue to do our homeworks concerning a project we have to build a wiki for our enterprise: 80 000 employees, but only 1000 of them could have access to the wiki: usually in read, some people in read/write. We will need per namespace security: some namespaces should not be read by some groups… We don’t want to go with many tons of wikis installation…
I wrote a post on another mailing list about it a couple of days ago: http://www.gossamer-threads.com/lists/wiki/mediawiki/381274
I had some very good and helpful comments, but it’s after that I found another mailing list (this one), which seems dedicated to the enterprise usage of Mediaiwki.
Here are the requierement we have:
Main page
NamespaceA (read for departmentA only)NamespaceB (read for departmentB only)….NamespaceZ (read for departmentZ)Sometimes, someone of departmentA will need read access to NamespaceZ, etc…
I would like to have some testimonials: your experiences, your recommendations… on a specific aspect of Mediawiki: ACL !!! (recurring topic, I believe…).
I read http://blog.blue-spice.org/2012/10/23/mediawiki-vs-confluence-not-a-qu estion-of-features/ and found that they use Lockdown and some other extensions around it, to secure the wiki
As everyone, I read http://www.mediawiki.org/wiki/Security_issues_with_authorization_exten sions and http://www.mediawiki.org/wiki/Category:Page_specific_user_rights_exten sions
So, I wrote to BlueSpice team to know if they believe that Lockdown is really secure to write sensitive data in a Mediawiki wiki. Answer was honest: no (as expected).
I wrote also to the guy who founded Intelpedia (Josh Bancroft) and he confirms that Mediawiki is the wrong tool to manage that kind of ACL and that they use other tools for sensitive data, not their wiki… I didn’t insist to know which other tool… I was impressed that a guy at this level take the time to answer me, so… J
Anyway, could you tell me what is the kind of setup you have on this side (ACL) ? Certainly that some of you use in the facts an ACL extension (Lockdown or others) ? Do you trust them ? Do you have implement some other kind of security ? etc… Wikifarm ? etc…
Sincerely, I believe I have read enough on the web about the subject… now, I need some concrete experiences, from real persons, in real enterprises,…
Voilà.
Thanks !
Pierre
Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
_______________________________________________ Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
Hi Pierre! I understand your dilemma perfectly well.
So, do we have to conclude that Mediawiki isn't a good choice for an enterprise (with these requierements) ???
Essencialy, yeah, MediaWiki sucks for the situations where you have sensitive data stored on your pages and possible attackers.
And no money for paid wikis (Confluence and cie).
Well that's weird. You've described that the wiki will be used in such a big scale... it seems to be pretty important project to spend several thousand bucks (=salary of 1-3 employees for month) on it and buy the TWiki or Confluence license.
For MediaWiki I can recommend IntraACL as well, but you have to be sure that there is no potential attackers in your case. ----- Yury Katkov, WikiVote
On Sat, Aug 24, 2013 at 3:59 AM, Pierre Labrecque pierre.labrecque@live.ca wrote:
So, do we have to conclude that Mediawiki isn't a good choice for an enterprise (with these requierements) ??? I can't say to our management: "hey ! pay for a developer to patch Lockdown and the core...and in a couple of months/years, the hole system may fail after an upgrade of MW..." (caricature). :-)
The context: 1- many customers: for each customers, we have many teams to support them. Each of these teams needs a "secure space" for its documents. 2- of course, all these teams (dedicated to different customers) share some general documents. We don't need or want to secure everything: a lot of stuff can be shared by everyone.
Here is the design we try to explore actually: 1- create a shared wiki (in our office) 2- create a single wiki, on the network of a customer (so if 100 customers, it means 100 wikis: one per customer, each one on the customer network)
As it doesn't make sense for us that an employee of customer X visits the shared wiki to have access to general documents, then visits its own wiki (on the customer network) to access restricted stuff, we though to put in place a system where the admin of the customer wiki access the shared wiki and pulls some interesting info from the shared to the customer wiki. It has its limits... just a possibility...
So let's say it's a good idea... it means that the customer wiki will be accessible by all our employees dedicated to this customer... but in this wiki, there are many documents too, that we need to secure too. So:
1- Shared Wiki: (accessible by all admin of customer wikis, these admin pull info from it to put general stuff in their own wiki) 2- Customers Wikis (accessible by our people, located on the customers facilities) 3- Customers Wikis: accessible by each of our employees, dedicated to this customers. So if Jack and Daniel work for CompanyA, it means that both will log into the CompanyA wiki. 4- Customers Wikis: Jack and Daniel have different roles. Jack is a computer technician and must have access to general software procedures. Daniel works with servers and is specialized in the firewall configuration of this customer... Jack should not see the stuff of Daniel, right ? We believe that this info is sensitive... So it means that we need to secure some namespace (for example) to prevent Jack to access Daniel stuff... So LockDown extension ? 5- Security: here, if MW with Lockdown fails, it will be a failure which will stay on the customer network (damage is limited, but absolutely not desirable!!!). That's one of the reason we prefer to separate general stuff (shared wiki) from the customer wiki (sensitive): isolation of the failure. If we put Lockdown on a single wiki, shared by all, and that a failure occurs: it means that every customer may be able to access the data of everyone else (firewall config for example...).
That's where we are for now... Yes: Dokuwiki, MoinMoin, etc... have ACL and are cerftainly the best choice for medium size wikis. But what's append with these wiki engines when you have 200/300/400 000 - 1 000 000 pages ? Are they seriously designed to support all these pages/images/doc, etc ? The search feature will become slow ? etc... we don't know... And no money for paid wikis (Confluence and cie).
What else: there are a tons of wiki engines. Why we prefer to have Mediawiki ? Well... to be honest... it's Mediawiki :-)
I sincerely hope that my English is clear... :-)
Cheers !
-----Original Message----- From: mediawiki-enterprise-bounces@lists.wikimedia.org [mailto:mediawiki-enterprise-bounces@lists.wikimedia.org] On Behalf Of Yury Katkov Sent: Friday, August 23, 2013 6:32 PM To: MediaWiki for enterprises Subject: Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?
I guess that one option for you will be to hire somebody or some company for developing Lockdown further so that they can cover all the holes from which the information can bet got. HalloWelt itself is a perfect candidate and we also have a lot more developers available [1]. Probably you will also want to hire different contractor that will try to steal the data from the modified extension.
Of course, after some time the extension will stop working because of ugly hacks that will definetely appear in the code.
Another and more proper solution is not so fast, that is: to lobby the proper ACL support in MediaWiki core before starting development. MediaWiki is used as an enterprise wiki and the impossibility of good ACL should not be considered as not some kind of philosophy of the software (as some people claims) but as a bug that needs fixing. Still even in this case the actual development of ACL won't be done by WMF - they aren't just interested in it. But if we would have carte blanche for patching the core and not been declined because "MW is an Open System, it has not been Designed to allow ACL support", I think many parties will be interested to fund the development.
[1] www.mediawiki.org/wiki/Professional_development_and_consulting
Yury Katkov, WikiVote
On Sat, Aug 24, 2013 at 1:36 AM, Pierre Labrecque pierre.labrecque@live.ca wrote:
Hello,
We continue to do our homeworks concerning a project we have to build a wiki for our enterprise: 80 000 employees, but only 1000 of them could have access to the wiki: usually in read, some people in read/write. We will need per namespace security: some namespaces should not be read by some groups… We don’t want to go with many tons of wikis installation…
I wrote a post on another mailing list about it a couple of days ago: http://www.gossamer-threads.com/lists/wiki/mediawiki/381274
I had some very good and helpful comments, but it’s after that I found another mailing list (this one), which seems dedicated to the enterprise usage of Mediaiwki.
Here are the requierement we have:
Main page
NamespaceA (read for departmentA only)NamespaceB (read for departmentB only)….NamespaceZ (read for departmentZ)Sometimes, someone of departmentA will need read access to NamespaceZ, etc…
I would like to have some testimonials: your experiences, your recommendations… on a specific aspect of Mediawiki: ACL !!! (recurring topic, I believe…).
I read http://blog.blue-spice.org/2012/10/23/mediawiki-vs-confluence-not-a-qu estion-of-features/ and found that they use Lockdown and some other extensions around it, to secure the wiki
As everyone, I read http://www.mediawiki.org/wiki/Security_issues_with_authorization_exten sions and http://www.mediawiki.org/wiki/Category:Page_specific_user_rights_exten sions
So, I wrote to BlueSpice team to know if they believe that Lockdown is really secure to write sensitive data in a Mediawiki wiki. Answer was honest: no (as expected).
I wrote also to the guy who founded Intelpedia (Josh Bancroft) and he confirms that Mediawiki is the wrong tool to manage that kind of ACL and that they use other tools for sensitive data, not their wiki… I didn’t insist to know which other tool… I was impressed that a guy at this level take the time to answer me, so… J
Anyway, could you tell me what is the kind of setup you have on this side (ACL) ? Certainly that some of you use in the facts an ACL extension (Lockdown or others) ? Do you trust them ? Do you have implement some other kind of security ? etc… Wikifarm ? etc…
Sincerely, I believe I have read enough on the web about the subject… now, I need some concrete experiences, from real persons, in real enterprises,…
Voilà.
Thanks !
Pierre
Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
Hi Pierre! I understand your dilemma perfectly well.
So, do we have to conclude that Mediawiki isn't a good choice for an enterprise (with these requierements) ???
Essencialy, yeah, MediaWiki sucks for the situations where you have sensitive data stored on your pages and possible attackers.
And no money for paid wikis (Confluence and cie).
Well that's weird. You've described that the wiki will be used in such a big scale... it seems to be pretty important project to spend several thousand bucks (=salary of 1-3 employees for month) on it and buy the TWiki or Confluence license.
For MediaWiki I can recommend IntraACL as well, but you have to be sure that there is no potential attackers in your case.
Just to note, we have a setup consisting of several wikis as well; and we have automatic replication set up between them (through import/export and configs/maintenance/replicate.php script); and in each separate wiki there are many projects which sometimes have (and sometimes don't have) different access rights.
But 100+ different customers isn't our case... so it's simpler for us. An idea is to use a namespace for each customer for the isolation :) it would be very simple for users and I think the isolation would be strict enough with IntraACL. The problem would be the File namespace, but there's NSFileRepo extension... it allows to use more than one namespace for files. But of course it should be checked first.
Also, about the dilemma - I would still recommend MediaWiki, and it's not the performance on big databases which matters, but the extensibility.
On 24 August 2013 11:14, Yury Katkov katkov.juriy@gmail.com wrote:
Well that's weird. You've described that the wiki will be used in such a big scale... it seems to be pretty important project to spend several thousand bucks (=salary of 1-3 employees for month) on it and buy the TWiki or Confluence license.
Confluence is also an incredible resource hog. (MW is fat, but it's got nothing on Confluence.) Budget for four servers (two frontend, two MySQL) if you have any substantial number of users.
- d.
Oops sorry Pierre, the namespaces were your original idea. :) I was answering too fast (before I've read your previous messages) :)
On 08/23/2013 06:31 PM, Yury Katkov wrote:
Of course, after some time the extension will stop working because of ugly hacks that will definetely appear in the code.
Another and more proper solution is not so fast, that is: to lobby the proper ACL support in MediaWiki core before starting development.
+1
Markus Glaser and I have discussed precisely this as one of the biggest hurdles for Corporate adoption of MediaWiki. There are a lot of things to do in the MediaWiki space but, as you point out, this is one that we need developers outside the WMF for.
MediaWiki is used as an enterprise wiki and the impossibility of good ACL should not be considered as not some kind of philosophy of the software (as some people claims) but as a bug that needs fixing.
+1 (again. That makes 2 points for Yury, so far.)
So if -- as many of us on the -enterprise mailing list agree, I think -- this is a bug that needs fixing, how are we going to fix it?
That is, where is the money to pay for developer time going to come from?
The release manager contractor[1] that the WMF is funding this year is meant to be finding funds outside of the Foundation to sustain release management long term. One way to do that is to begin extending MediaWiki in ways that enterprises would be willing to fund -- say, for example. through developing ACLs.
If we can find some MW developers interested in working on adding this to core, and the money to fund those developer's work, the problem then becomes coordinating their work and making sure it has real momentum.
Thoughts?
Hi all!
About ACLs - do you know about our "IntraACL" extension? (based on earlier one "HaloACL" by ontoprise company)
https://github.com/mediawiki4intranet/IntraACL/
It has full protection of pages for reading via core patches, in listings and etc; ACLs can be configured on a page, category or namespace basis.
"Stable" version consists of a totally rewritten UI and a modified HaloACL backend (though not so heavily modified). Now we use it on our corporate wikis.
But just like the UI was, HaloACL backend is also designed very poorly (it's slow and it's written too verbosely), so now I'm doing a total rewrite of it - it's in the "storage-rewrite" git branch. It's almost ready, I should just test it and add some additional maintenance features. Automated tests are also in development now.
Of course the extension isn't perfect - there are some ideological problems, for example some combinations of page/category/namespace rights are not always obvious for users (and there are 3 override modes); page/category/namespace ACLs are a mess if you want to really restrict editing of ACLs themselves; also, now there is a hardcode - "sysop" and "bureaucrat" MW groups are always super-users.
But assuming you have no people that want to _really_ abuse your right system - which is usually a correct assumption in corporate environment - the extension is good enough for everyday use.
So! :)
Everyone is welcome to test it and tell us about good ideas if you have some :) (my main question which I can't really solve by myself is - what right system would be really convenient to use in MediaWiki's flat page structure with categories?)
Good morning from Canada,
First of all: thank you for all your comments and efforts ! I really appreciate all of them ! When I see all this, I take confidence in the human being... You have all my respect.
Seems that we may have a potential solution (?) :-)
I know that we can't close all doors... it is perhaps not prevent all risks, but to learn how to manage the limit (can we say that in english ???)
I downloaded IntraACL from the "storage-rewrite" git branch to do a test. Under patches/ there is no IntraACL-MediaWiki-*.diff for our Mediawiki version: 1.21.1 Anyway, I have done a backup of our dev virtual machine and then try to to apply IntraACL-MediaWiki-1.20.3.diff to our 1.21.1 installation (just to try and guess): of course I got some errors on lines xxxx...
Question: is there a IntraACL-MediaWiki-xxx.diff for 1.21.1 somewhere ? Else, do you suggest to install 1.20.3 (or 1.20.6) instead of the latest MV version ? (because there is an available diff for 1.20.3...)
Again: thanks you all !!!!
Pierre
-----Original Message----- From: mediawiki-enterprise-bounces@lists.wikimedia.org [mailto:mediawiki-enterprise-bounces@lists.wikimedia.org] On Behalf Of vitalif@yourcmc.ru Sent: Saturday, August 24, 2013 6:03 AM To: mediawiki-enterprise@lists.wikimedia.org Subject: Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?
Hi all!
About ACLs - do you know about our "IntraACL" extension? (based on earlier one "HaloACL" by ontoprise company)
https://github.com/mediawiki4intranet/IntraACL/
It has full protection of pages for reading via core patches, in listings and etc; ACLs can be configured on a page, category or namespace basis.
"Stable" version consists of a totally rewritten UI and a modified HaloACL backend (though not so heavily modified). Now we use it on our corporate wikis.
But just like the UI was, HaloACL backend is also designed very poorly (it's slow and it's written too verbosely), so now I'm doing a total rewrite of it - it's in the "storage-rewrite" git branch. It's almost ready, I should just test it and add some additional maintenance features. Automated tests are also in development now.
Of course the extension isn't perfect - there are some ideological problems, for example some combinations of page/category/namespace rights are not always obvious for users (and there are 3 override modes); page/category/namespace ACLs are a mess if you want to really restrict editing of ACLs themselves; also, now there is a hardcode - "sysop" and "bureaucrat" MW groups are always super-users.
But assuming you have no people that want to _really_ abuse your right system - which is usually a correct assumption in corporate environment - the extension is good enough for everyday use.
So! :)
Everyone is welcome to test it and tell us about good ideas if you have some :) (my main question which I can't really solve by myself is - what right system would be really convenient to use in MediaWiki's flat page structure with categories?)
-- With best regards, Vitaliy Filippov
_______________________________________________ Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
First of all: thank you for all your comments and efforts ! I really appreciate all of them ! When I see all this, I take confidence in the human being... You have all my respect.
Seems that we may have a potential solution (?) :-)
I know that we can't close all doors... it is perhaps not prevent all risks, but to learn how to manage the limit (can we say that in english ???)
I downloaded IntraACL from the "storage-rewrite" git branch to do a test. Under patches/ there is no IntraACL-MediaWiki-*.diff for our Mediawiki version: 1.21.1 Anyway, I have done a backup of our dev virtual machine and then try to to apply IntraACL-MediaWiki-1.20.3.diff to our 1.21.1 installation (just to try and guess): of course I got some errors on lines xxxx...
Question: is there a IntraACL-MediaWiki-xxx.diff for 1.21.1 somewhere ? Else, do you suggest to install 1.20.3 (or 1.20.6) instead of the latest MV version ? (because there is an available diff for 1.20.3...)
Again: thanks you all !!!!
I'm sure storage-rewrite still has bugs, so I think you should better take master by now. Rewritten version will be totally compatible with current one (the update will be as easy as just running maintenance/update.php).
I've updated the patch for 1.21.1 - it's not so hard, but I didn't test the result yet :-)) you can pull from master and try it out :)
Hello !
I tried and got this error:
-----Original Message----- From: mediawiki-enterprise-bounces@lists.wikimedia.org [mailto:mediawiki-enterprise-bounces@lists.wikimedia.org] On Behalf Of vitalif@yourcmc.ru Sent: Saturday, August 24, 2013 11:35 AM To: MediaWiki for enterprises Subject: Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?
First of all: thank you for all your comments and efforts ! I really appreciate all of them ! When I see all this, I take confidence in the human being... You have all my respect.
Seems that we may have a potential solution (?) :-)
I know that we can't close all doors... it is perhaps not prevent all risks, but to learn how to manage the limit (can we say that in english ???)
I downloaded IntraACL from the "storage-rewrite" git branch to do a test. Under patches/ there is no IntraACL-MediaWiki-*.diff for our Mediawiki version: 1.21.1 Anyway, I have done a backup of our dev virtual machine and then try to to apply IntraACL-MediaWiki-1.20.3.diff to our 1.21.1 installation (just to try and guess): of course I got some errors on lines xxxx...
Question: is there a IntraACL-MediaWiki-xxx.diff for 1.21.1 somewhere ? Else, do you suggest to install 1.20.3 (or 1.20.6) instead of the latest MV version ? (because there is an available diff for 1.20.3...)
Again: thanks you all !!!!
I'm sure storage-rewrite still has bugs, so I think you should better take master by now. Rewritten version will be totally compatible with current one (the update will be as easy as just running maintenance/update.php).
I've updated the patch for 1.21.1 - it's not so hard, but I didn't test the result yet :-)) you can pull from master and try it out :)
_______________________________________________ Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
Hello,
Thanks for the update !
I tried with the latest in git (master) and got this error:
root@euswebsrv01:/var/www/sites/mediawiki001# php maintenance/update.php ** WARNING: IntraACL security checks are disabled because ** $_SERVER[SERVER_NAME] is empty, which probably means we are in console PHP Fatal error: Call to undefined function wfLoadExtensionMessages() in /var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_GlobalFunctions.php on line 178
Idea ?
Cheers !
Pierre
-----Original Message----- From: mediawiki-enterprise-bounces@lists.wikimedia.org [mailto:mediawiki-enterprise-bounces@lists.wikimedia.org] On Behalf Of vitalif@yourcmc.ru Sent: Saturday, August 24, 2013 11:35 AM To: MediaWiki for enterprises Subject: Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?
First of all: thank you for all your comments and efforts ! I really appreciate all of them ! When I see all this, I take confidence in the human being... You have all my respect.
Seems that we may have a potential solution (?) :-)
I know that we can't close all doors... it is perhaps not prevent all risks, but to learn how to manage the limit (can we say that in english ???)
I downloaded IntraACL from the "storage-rewrite" git branch to do a test. Under patches/ there is no IntraACL-MediaWiki-*.diff for our Mediawiki version: 1.21.1 Anyway, I have done a backup of our dev virtual machine and then try to to apply IntraACL-MediaWiki-1.20.3.diff to our 1.21.1 installation (just to try and guess): of course I got some errors on lines xxxx...
Question: is there a IntraACL-MediaWiki-xxx.diff for 1.21.1 somewhere ? Else, do you suggest to install 1.20.3 (or 1.20.6) instead of the latest MV version ? (because there is an available diff for 1.20.3...)
Again: thanks you all !!!!
I'm sure storage-rewrite still has bugs, so I think you should better take master by now. Rewritten version will be totally compatible with current one (the update will be as easy as just running maintenance/update.php).
I've updated the patch for 1.21.1 - it's not so hard, but I didn't test the result yet :-)) you can pull from master and try it out :)
_______________________________________________ Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
Maybe ??? http://www.mediawiki.org/wiki/Thread:Project:Support_desk/wfLoadExtensionMes... I'm not a programmer :-) ....
-----Original Message----- From: mediawiki-enterprise-bounces@lists.wikimedia.org [mailto:mediawiki-enterprise-bounces@lists.wikimedia.org] On Behalf Of Pierre Labrecque Sent: Saturday, August 24, 2013 12:51 PM To: 'MediaWiki for enterprises' Subject: Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?
Hello,
Thanks for the update !
I tried with the latest in git (master) and got this error:
root@euswebsrv01:/var/www/sites/mediawiki001# php maintenance/update.php ** WARNING: IntraACL security checks are disabled because ** $_SERVER[SERVER_NAME] is empty, which probably means we are in console PHP Fatal error: Call to undefined function wfLoadExtensionMessages() in /var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_GlobalFunctions.php on line 178
Idea ?
Cheers !
Pierre
-----Original Message----- From: mediawiki-enterprise-bounces@lists.wikimedia.org [mailto:mediawiki-enterprise-bounces@lists.wikimedia.org] On Behalf Of vitalif@yourcmc.ru Sent: Saturday, August 24, 2013 11:35 AM To: MediaWiki for enterprises Subject: Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?
First of all: thank you for all your comments and efforts ! I really appreciate all of them ! When I see all this, I take confidence in the human being... You have all my respect.
Seems that we may have a potential solution (?) :-)
I know that we can't close all doors... it is perhaps not prevent all risks, but to learn how to manage the limit (can we say that in english ???)
I downloaded IntraACL from the "storage-rewrite" git branch to do a test. Under patches/ there is no IntraACL-MediaWiki-*.diff for our Mediawiki version: 1.21.1 Anyway, I have done a backup of our dev virtual machine and then try to to apply IntraACL-MediaWiki-1.20.3.diff to our 1.21.1 installation (just to try and guess): of course I got some errors on lines xxxx...
Question: is there a IntraACL-MediaWiki-xxx.diff for 1.21.1 somewhere ? Else, do you suggest to install 1.20.3 (or 1.20.6) instead of the latest MV version ? (because there is an available diff for 1.20.3...)
Again: thanks you all !!!!
I'm sure storage-rewrite still has bugs, so I think you should better take master by now. Rewritten version will be totally compatible with current one (the update will be as easy as just running maintenance/update.php).
I've updated the patch for 1.21.1 - it's not so hard, but I didn't test the result yet :-)) you can pull from master and try it out :)
_______________________________________________ Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
_______________________________________________ Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
On 08/24/2013 12:51 PM, Pierre Labrecque wrote:
PHP Fatal error: Call to undefined function wfLoadExtensionMessages()
Comment out line 178 of extensions/IntraACL/includes/HACL_GlobalFunctions.php and it should work.
I'll submit a patch for the extension.
FYI: I commented line 178 of extensions/IntraACL/includes/HACL_GlobalFunctions.php
I modified LocalSettings.php (add the next 2 lines):
require_once("$IP/extensions/IntraACL/includes/HACL_Initialize.php"); enableIntraACL();
Then: cd /var/www/sites/mediawiki001 patch -p1 extensions/IntraACL/patches/IntraACL-MediaWiki-1.21.1.diff
When I press ENTER after the patch command, nothing append... it stay there forever... Just a cursor that doesn't blink, nothing...
??????
-----Original Message----- From: Mark A. Hershberger [mailto:mah@nichework.com] Sent: Saturday, August 24, 2013 1:23 PM To: MediaWiki for enterprises Cc: Pierre Labrecque Subject: Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?
On 08/24/2013 12:51 PM, Pierre Labrecque wrote:
PHP Fatal error: Call to undefined function wfLoadExtensionMessages()
Comment out line 178 of extensions/IntraACL/includes/HACL_GlobalFunctions.php and it should work.
I'll submit a patch for the extension.
On 08/24/2013 03:22 PM, Pierre Labrecque wrote:
cd /var/www/sites/mediawiki001 patch -p1 extensions/IntraACL/patches/IntraACL-MediaWiki-1.21.1.diff
When I press ENTER after the patch command, nothing append... it stay there forever... Just a cursor that doesn't blink, nothing...
You are missing a character:
patch -p1 < extensions/IntraACL/patches/IntraACL-MediaWiki-1.21.1.diff
You see the blinking cursor and nothing else because patch is stupid and doesn't see that you've given it the patch file on the command line. It expects to read it from STDIN and that is what the "<" does.
)(*&?)?&%(&?%$()(*%? I feel stupid... sorry about this one... Thanks !
-----Original Message----- From: Mark A. Hershberger [mailto:mah@everybody.org] Sent: Saturday, August 24, 2013 3:39 PM To: MediaWiki for enterprises Cc: Pierre Labrecque Subject: Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?
On 08/24/2013 03:22 PM, Pierre Labrecque wrote:
cd /var/www/sites/mediawiki001 patch -p1 extensions/IntraACL/patches/IntraACL-MediaWiki-1.21.1.diff
When I press ENTER after the patch command, nothing append... it stay there forever... Just a cursor that doesn't blink, nothing...
You are missing a character:
patch -p1 < extensions/IntraACL/patches/IntraACL-MediaWiki-1.21.1.diff
You see the blinking cursor and nothing else because patch is stupid and doesn't see that you've given it the patch file on the command line. It expects to read it from STDIN and that is what the "<" does.
Love alone reveals the true shape of the universe. -- "Everywhere Present", Stephen Freeman
Now able to get the login page, but as soon I try to access something else, I get an Error 500: Apache error log give:
[Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Notice: Only variable references should be returned by reference in /var/www/sites/mediawiki001/includes/Title.php on line 343, referer: http://servername/sites/mediawiki001/index.php?title=Special:UserLogin
[Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Notice: Undefined variable: titleObj in /var/www/sites/mediawiki001/includes/specials/SpecialUserlogin.php on line 1004, referer: http:// servername /sites/mediawiki001/index.php?title=Special:UserLogin
[Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Notice: Only variable references should be returned by reference in /var/www/sites/mediawiki001/includes/Title.php on line 343, referer: http:// servername /sites/mediawiki001/index.php?title=Special:UserLogin
[Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Parse error: syntax error, unexpected T_OBJECT_OPERATOR in /var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ParserFunctions.php on line 1365, referer: http:// servername /sites/mediawiki001/index.php?title=Special:UserLogin
FYI: Ubuntu 12.04.2 Server (x64) Apache/2.2.22 (Ubuntu) PHP Version 5.3.10-1ubuntu3.7 MySQL 5.5.29-0ubuntu0.12.04.1 x86_64 Mediawiki 1.21.1
Cheers !
-----Original Message----- From: Mark A. Hershberger [mailto:mah@everybody.org] Sent: Saturday, August 24, 2013 3:39 PM To: MediaWiki for enterprises Cc: Pierre Labrecque Subject: Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?
On 08/24/2013 03:22 PM, Pierre Labrecque wrote:
cd /var/www/sites/mediawiki001 patch -p1 extensions/IntraACL/patches/IntraACL-MediaWiki-1.21.1.diff
When I press ENTER after the patch command, nothing append... it stay there forever... Just a cursor that doesn't blink, nothing...
You are missing a character:
patch -p1 < extensions/IntraACL/patches/IntraACL-MediaWiki-1.21.1.diff
You see the blinking cursor and nothing else because patch is stupid and doesn't see that you've given it the patch file on the command line. It expects to read it from STDIN and that is what the "<" does.
Love alone reveals the true shape of the universe. -- "Everywhere Present", Stephen Freeman
[Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Notice: Only variable references should be returned by reference in /var/www/sites/mediawiki001/includes/Title.php on line 343, referer:
http://servername/sites/mediawiki001/index.php?title=Special:UserLogin
Fixed, I didn't notice makeTitle is still "function &makeTitle(...)". Is & still needed here? (question to Mark or someone else)
[Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Notice: Undefined variable: titleObj in /var/www/sites/mediawiki001/includes/specials/SpecialUserlogin.php on line 1004, referer: http:// servername /sites/mediawiki001/index.php?title=Special:UserLogin
This one came from a previous patch (1.20.3). Fixed in master for both patches (1.20.3 and 1.21.1).
[Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Notice: Only variable references should be returned by reference in /var/www/sites/mediawiki001/includes/Title.php on line 343, referer: http:// servername /sites/mediawiki001/index.php?title=Special:UserLogin
Same as first.
[Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Parse error: syntax error, unexpected T_OBJECT_OPERATOR in
/var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ParserFunctions.php on line 1365, referer: http:// servername /sites/mediawiki001/index.php?title=Special:UserLogin
This one was an incompatibility with PHP 5.3 (it worked with 5.4+). Fixed.
FYI: Ubuntu 12.04.2 Server (x64) Apache/2.2.22 (Ubuntu) PHP Version 5.3.10-1ubuntu3.7 MySQL 5.5.29-0ubuntu0.12.04.1 x86_64 Mediawiki 1.21.1
Cheers !
Please try the master version again :)
Hello,
Wow !!! Thanks for your time !!!
Installation went well that time. I didn't see errors during the patch and update.php. I notice some errors in Apache error.log:
Sun Aug 25 11:21:06 2013] [notice] Apache/2.2.22 (Ubuntu) PHP/5.3.10-1ubuntu3.7 with Suhosin-Patch configured -- resuming normal operations
[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Notice: Undefined variable: cluster in /var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on line 282, referer: http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACL&ac...
[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Warning: Invalid argument supplied for foreach() in /var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on line 282, referer: http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACL&ac...
[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Notice: Undefined index: in /var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on line 341, referer: http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACL&ac...
[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Warning: Invalid argument supplied for foreach() in /var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on line 341, referer: http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACL&ac...
[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Notice: Undefined variable: edges in /var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on line 357, referer: http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACL&ac...
[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Warning: Invalid argument supplied for foreach() in /var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on line 357, referer: http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACL&ac...
Also: I went to Special:IntraACL and understand that I will have to learn how it works :-) Is there a kind of "user guide" somewhere ? (in English, if possible :-), else I will try with Google Translate if in Russian...) I believe that http://wiki.4intra.net/IntraACL/ru is the user guide ???
Also: not sure, but I believe to have read somewhere that IntraACL isn't compatible with Semantic ? True ? False ?
Thanks again !
Pierre
-----Original Message----- From: mediawiki-enterprise-bounces@lists.wikimedia.org [mailto:mediawiki-enterprise-bounces@lists.wikimedia.org] On Behalf Of vitalif@yourcmc.ru Sent: Sunday, August 25, 2013 10:52 AM To: MediaWiki for enterprises Subject: Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?
[Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Notice: Only variable references should be returned by reference in /var/www/sites/mediawiki001/includes/Title.php on line 343, referer:
http://servername/sites/mediawiki001/index.php?title=Special:UserLogin
Fixed, I didn't notice makeTitle is still "function &makeTitle(...)". Is & still needed here? (question to Mark or someone else)
[Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Notice: Undefined variable: titleObj in /var/www/sites/mediawiki001/includes/specials/SpecialUserlogin.php on line 1004, referer: http:// servername /sites/mediawiki001/index.php?title=Special:UserLogin
This one came from a previous patch (1.20.3). Fixed in master for both patches (1.20.3 and 1.21.1).
[Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Notice: Only variable references should be returned by reference in /var/www/sites/mediawiki001/includes/Title.php on line 343, referer: http:// servername /sites/mediawiki001/index.php?title=Special:UserLogin
Same as first.
[Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Parse error: syntax error, unexpected T_OBJECT_OPERATOR in
/var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ParserFu nctions.php on line 1365, referer: http:// servername /sites/mediawiki001/index.php?title=Special:UserLogin
This one was an incompatibility with PHP 5.3 (it worked with 5.4+). Fixed.
FYI: Ubuntu 12.04.2 Server (x64) Apache/2.2.22 (Ubuntu) PHP Version 5.3.10-1ubuntu3.7 MySQL 5.5.29-0ubuntu0.12.04.1 x86_64 Mediawiki 1.21.1
Cheers !
Please try the master version again :)
_______________________________________________ Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Notice: Undefined variable: cluster in
/var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on line 282, referer:
http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACL&ac...
[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Warning: Invalid argument supplied for foreach() in
/var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on line 282, referer:
http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACL&ac...
[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Notice: Undefined index: in
/var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on line 341, referer:
http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACL&ac...
[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Warning: Invalid argument supplied for foreach() in
/var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on line 341, referer:
http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACL&ac...
[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Notice: Undefined variable: edges in
/var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on line 357, referer:
http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACL&ac...
[Sun Aug 25 11:22:32 2013] [error] [client 192.168.0.100] PHP Warning: Invalid argument supplied for foreach() in
/var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ACLSpecial.php on line 357, referer:
http://SERVERNAME/sites/mediawiki001/index.php?title=Special:IntraACL&ac...
These warnings went from the "rightgraph" tab - this was an experiment to display all defined ACLs graphically using Graphviz. So, it seems it emits warnings when no ACLs are defined. Nothing to worry about, and maybe I've already fixed it in the storage-rewrite branch...
Also: I went to Special:IntraACL and understand that I will have to learn how it works :-)
It's not that hard... rights are set on ACLs, ACL is a wikipage with special content in ACL namespace. ACLs can be created for pages, categories and namespaces. By default they are additive, i.e. if page X is in a protected namespace, has two protected categories and also has page ACL set for it, the rights from all these ACLs are summarized.
Category ACL affects pages that are in the category and its subcategories, and also the category page itself ("Category:X"). Namespace ACL obviously affects pages from that namespace. Page ACL affects single page.
To create page or category ACL the simplest is to use "ACL" tab which is displayed between "page" and "talk" tabs on the top. Just click it and the ACL article will show up. Then you click "create with editor". In the editor, select right target type - user/group/* (all users)/# (all registered users)) in the selectbox on the right, and start typing the target (user/group) name - the input has autocomplete. Then use checkboxes to grant rights to the selected target. The editor composes corresponding wikitext and then you save it using Save button [ :-) ]
Also you can access the editor from Special:IntraACL ("create ACL"), for example to create namespace ACL.
Groups aren't MediaWiki builtin like "sysop", IntraACL uses its own groups that are also managed from Special:IntraACL under "groups"/"create group". The UI is similar to that of ACLs.
Is there a kind of "user guide" somewhere ? (in English, if possible :-), else I will try with Google Translate if in Russian...) I believe that http://wiki.4intra.net/IntraACL/ru is the user guide ???
Kind of... There's no real "user guide", mostly it explains some concepts about ACLs and differences from HaloACL. But there's something to learn, anyway.
Also: not sure, but I believe to have read somewhere that IntraACL isn't compatible with Semantic ? True ? False ?
Yes, it is, in the sense of that it doesn't protect SMW properties and query results. It's mentioned on http://wiki.4intra.net/IntraACL/ru mostly because the original extension (HaloACL) tried to protect them in some weird manner (they've tried to encrypt them and then decrypt in some places O_o)... And because I've removed this feature.
It's basically "incompatible" with any extension that does direct database access - i.e. its usage may lead to leaks. But it's usually simple to make it "compatible" by just adding userCanRead() checks. Extensions that we use are already patched, you can take them from github.
Hi Vitaliy,
Do you have any plans to add support of Semantic Mediawiki into IntraACL? We tried to use HaloACL on our wikis, but there are too many bugs and problems on large amount of articles
-- Evgeniy Dankovcev
On Aug 25, 2013, at 11:24, vitalif@yourcmc.ru wrote:
Also: not sure, but I believe to have read somewhere that IntraACL isn't compatible with Semantic ? True ? False ?
Yes, it is, in the sense of that it doesn't protect SMW properties and query results. It's mentioned on http://wiki.4intra.net/IntraACL/ru mostly because the original extension (HaloACL) tried to protect them in some weird manner (they've tried to encrypt them and then decrypt in some places O_o)... And because I've removed this feature.
It's basically "incompatible" with any extension that does direct database access - i.e. its usage may lead to leaks. But it's usually simple to make it "compatible" by just adding userCanRead() checks. Extensions that we use are already patched, you can take them from github.
Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
Hi Vitaliy,
Do you have any plans to add support of Semantic Mediawiki into IntraACL? We tried to use HaloACL on our wikis, but there are too many bugs and problems on large amount of articles
Hi, what support do you really want? I.e. do you want to protect properties like in HaloACL? (I've almost forgotten how it was done there... can you refresh it to me?)
Or normal page (subject) protection will be enough? The latter is in my plans, though for SMW it's slightly harder than for small extensions, and also by SMW people generally mean more semantic extensions... and they also need that support.
You can even do this patching job by yourself - it's simple, you just need to find places where the content is taken from / saved to the DB and add $title->userCanRead() checks there.
Our most interest is protecting query results via ACLs on Categories - so pages of specific categories would not be exposable to specific user groups
As for how haloacl deals with properties -as I remember it was dealing a bit weird - it protected the values of specific properties(in query results for those particular properties? Not sure) while the page itself was still exposable.
Our intention is to be able to hide pages with specific property values from query results (including hiding from sub-queries results, output of query to template, etc)
-- Evgeniy Dankovcev
On Aug 25, 2013, at 11:40, vitalif@yourcmc.ru wrote:
Hi Vitaliy,
Do you have any plans to add support of Semantic Mediawiki into IntraACL? We tried to use HaloACL on our wikis, but there are too many bugs and problems on large amount of articles
Hi, what support do you really want? I.e. do you want to protect properties like in HaloACL? (I've almost forgotten how it was done there... can you refresh it to me?)
Or normal page (subject) protection will be enough? The latter is in my plans, though for SMW it's slightly harder than for small extensions, and also by SMW people generally mean more semantic extensions... and they also need that support.
You can even do this patching job by yourself - it's simple, you just need to find places where the content is taken from / saved to the DB and add $title->userCanRead() checks there.
Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
Our most interest is protecting query results via ACLs on Categories
- so pages of specific categories would not be exposable to specific
user groups
OK, I think it's possible with normal $title->userCanRead() page protection.
Our intention is to be able to hide pages with specific property values from query results (including hiding from sub-queries results, output of query to template, etc)
Do you talk here about protecting the page if it has a specific property set to a specific value? It's of course harder to implement if you want to take properties and their values into account. But as I understand, category protection will suffice for you - correct?
Yes, that was my point. But anyway, protecting by category will be an awesome feature for the start
thanks for your reply :)
-- Evgeniy Dankovcev
On Aug 25, 2013, at 12:28, vitalif@yourcmc.ru wrote:
Do you talk here about protecting the page if it has a specific property set to a specific value? It's of course harder to implement if you want to take properties and their values into account. But as I understand, category protection will suffice for you - correct?
Mediawiki-enterprise mailing list Mediawiki-enterprise@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-enterprise
On 08/24/2013 04:12 PM, Pierre Labrecque wrote:
Now able to get the login page, but as soon I try to access something else, I get an Error 500: Apache error log give:
[Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Parse error: syntax error, unexpected T_OBJECT_OPERATOR in /var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ParserFunctions.php on line 1365, referer: http:// servername /sites/mediawiki001/index.php?title=Special:UserLogin
I can't T_OBJECT_OPERATOR anywhere in the code for IntrACL. Where do you see it in the code?
I can't T_OBJECT_OPERATOR anywhere in the code for IntrACL. Where do you see it in the code?
I've already fixed it, it was
(new Article($to))->doDeleteArticle(wfMsg('hacl_move_acl'));
PHP 5.3 does not allow to call a method on an expression.
Well. I don't know too ! :-) I didn't find it and opened all files from the extension... Anyway: I deleted my VM and restore it (from a backup just before installing IntraACL),redid the install procedure and that time, no errors in Apache error log. Can't understand why as I did the very same procedure (copy/paste). Also, that time, I have an ACL tab in each page (I didn't had it in my first try, didn't know it exists...)... I really don't understand... I have done exactly the same thing...
Here is the complete procedure I do:
1- edit LocalSettings.php and add these 2 lines: require_once("$IP/extensions/IntraACL/includes/HACL_Initialize.php"); enableIntraACL();
2- I restart Apache (I thinks it's better as maybe LocalSettings.php is in the cache...?): service apache2 restart
3- I run these commands and none of them give error: cd /var/www/sites/mediawiki001 patch -p1 < extensions/IntraACL/patches/IntraACL-MediaWiki-1.21.1.diff php maintenance/update.php
4- restart Apache again...
I browsed a lot in the site and Apache error log is perfect. The only error I have actually is: [Sun Aug 25 14:22:16 2013] [error] [client 192.168.0.100] File does not exist: /var/www/sites/mediawiki001/skins/common/edit.js, referer: http://SERVERNAME/sites/mediawiki001/index.php?title=Special:MultipleUpload Which doesn't concern IntraACL !!! (and MultipleUpload is probably not fully compatible with MW 1.21.x, so...)
I browsed the site and nothing else appear in the error.log...
????????????
Cheers !
-----Original Message----- From: Mark A. Hershberger [mailto:mah@nichework.com] Sent: Sunday, August 25, 2013 1:40 PM To: MediaWiki for enterprises Cc: Pierre Labrecque Subject: Re: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?
On 08/24/2013 04:12 PM, Pierre Labrecque wrote:
Now able to get the login page, but as soon I try to access something else, I get an Error 500: Apache error log give:
[Sat Aug 24 16:02:45 2013] [error] [client 192.168.0.100] PHP Parse error: syntax error, unexpected T_OBJECT_OPERATOR in /var/www/sites/mediawiki001/extensions/IntraACL/includes/HACL_ParserFu nctions.php on line 1365, referer: http:// servername /sites/mediawiki001/index.php?title=Special:UserLogin
I can't T_OBJECT_OPERATOR anywhere in the code for IntrACL. Where do you see it in the code?
-- Mark A. Hershberger NicheWork LLC 717-271-1084
Well. I don't know too ! :-) I didn't find it and opened all files from the extension...
:) T_OBJECT_OPERATOR token is "->" for PHP. Didn't you see T_PAAMAYIM_NEKUDOTAYIM yet? :) that is hebrew for "::" :)
2- I restart Apache (I thinks it's better as maybe LocalSettings.php is in the cache...?): service apache2 restart
No, it's usually not cached. But of course an extra restart won't hurt :)
On 08/25/2013 02:46 PM, vitalif@yourcmc.ru wrote:
:) T_OBJECT_OPERATOR token is "->" for PHP. Didn't you see T_PAAMAYIM_NEKUDOTAYIM yet? :) that is hebrew for "::" :)
I knew about T_PAAMAYIM_NEKUDOTAYIM but not T_OBJECT_OPERATOR. Sometimes I really hate PHP.
Hi Pierre,
Your questions are crucial for enterprises but not easy to answer.
You can split up the content for different departments by using namespaces and lockdown. We have done this many times for customers and it works very well. The problem is sometimes the user interface, because the employees normally aren't familiar with the namespace concept, especially if they try to create a new page. We (in BlueSpice) give some support via the page template system. There you can say "I have a new page for Department A" and the template creates the new page in the new namespace. That's possible way, but that all can be improved :)
And there is sometimes trouble, because the uploaded media are all in the same namespace.
But mostly we find solutions, because images, office-documents are already in the file system or in a DMS or in SharePoint and we build a connector or offer the possibility to use file links. If your customers think twice, he often realizes, that he doesn't want all documents with all duplicates in the wiki and in the search results. The reading rights for these documents are mostly managed by the Active Directory or LDAP server. So there is no security problem for documents at all. But to have a "small DMS" in MediaWiki would be helpful or - better - plugins for nice open source systems like agorum. And what is about WebDAV?
For large companies, especially for transnational ones we recommend several wikis for different languages, departments or content types. I know Confluence and all the others promises all-in-one-solutions. That's sounds great for the CIO but for the usability it isn't. Several wikis are better for orientation (what is this wiki for ...), for searching in (results only in your language...) and regarding access control issues. Four or five wikis should be centrally organized in a wiki farm.
And, maybe an interesting alternative, we have realized a wiki switch for a supermarket corporation. So you can switch between a "public" wiki for partners and an internal wiki for staff members.
Best regards, Richard
Dr. Richard Heigl Strategieberatung
Hallo Welt! - Medienwerkstatt GmbH __________________________________
Residenzstraße 2 93047 Regensburg
Tel. +49 (0) 941 - 66 0 80-193 Fax +49 (0) 941 - 66 0 80-189
www.hallowelt.biz heigl@hallowelt.biz
Sitz: Regensburg Amtsgericht: Regensburg Handelsregister: HRB 10467 E.USt.Nr.: DE 253050833 Geschäftsführer: Anja Ebersbach, Markus Glaser, Dr. Richard Heigl, Radovan Kubani
Von: mediawiki-enterprise-bounces@lists.wikimedia.org [mailto:mediawiki-enterprise-bounces@lists.wikimedia.org] Im Auftrag von Pierre Labrecque Gesendet: Freitag, 23. August 2013 23:36 An: 'MediaWiki for enterprises' Betreff: [Mediawiki-enterprise] How do you manage the security in your Mediawiki installation (Enterprise wiki) ?
Hello,
We continue to do our homeworks concerning a project we have to build a wiki for our enterprise: 80 000 employees, but only 1000 of them could have access to the wiki: usually in read, some people in read/write. We will need per namespace security: some namespaces should not be read by some groups... We don't want to go with many tons of wikis installation...
I wrote a post on another mailing list about it a couple of days ago: http://www.gossamer-threads.com/lists/wiki/mediawiki/381274 I had some very good and helpful comments, but it's after that I found another mailing list (this one), which seems dedicated to the enterprise usage of Mediaiwki.
Here are the requierement we have:
Main page
- NamespaceA (read for departmentA only)
- NamespaceB (read for departmentB only)
- ....
- NamespaceZ (read for departmentZ) Sometimes, someone of departmentA will need read access to NamespaceZ, etc...
I would like to have some testimonials: your experiences, your recommendations... on a specific aspect of Mediawiki: ACL !!! (recurring topic, I believe...).
I read http://blog.blue-spice.org/2012/10/23/mediawiki-vs-confluence-not-a-question... and found that they use Lockdown and some other extensions around it, to secure the wiki As everyone, I read http://www.mediawiki.org/wiki/Security_issues_with_authorization_extensions and http://www.mediawiki.org/wiki/Category:Page_specific_user_rights_extensions So, I wrote to BlueSpice team to know if they believe that Lockdown is really secure to write sensitive data in a Mediawiki wiki. Answer was honest: no (as expected).
I wrote also to the guy who founded Intelpedia (Josh Bancroft) and he confirms that Mediawiki is the wrong tool to manage that kind of ACL and that they use other tools for sensitive data, not their wiki... I didn't insist to know which other tool... I was impressed that a guy at this level take the time to answer me, so... :)
Anyway, could you tell me what is the kind of setup you have on this side (ACL) ? Certainly that some of you use in the facts an ACL extension (Lockdown or others) ? Do you trust them ? Do you have implement some other kind of security ? etc... Wikifarm ? etc...
Sincerely, I believe I have read enough on the web about the subject... now, I need some concrete experiences, from real persons, in real enterprises,...
Voilà.
Thanks !
Pierre
mediawiki-enterprise@lists.wikimedia.org