Hi,
Attached is a patch to mediawiki that adds a new option $wgDontSaveIPs
What it does is allowing completely anonymous wikis by replacing the IP adress with 0.0.0.0.
(a bit background, there's a german campaign wirspeichernnicht.de, which wants to enforce a more anonymous web and provides a couple of descriptions how to disable ip saving in different apps - for mediawiki it tells to change the source, though I thought a clean option would be better: http://www.wirspeichernnicht.de/content/view/9/24/)
Attached patch is against mediawiki 1.15rc1. Would be nice if you would apply it.
Hanno Böck wrote:
Attached is a patch to mediawiki that adds a new option $wgDontSaveIPs
It's a bad idea to use a negative in a name. In English, it makes for confusing program statements with double negatives ( e.g. not don't save) It would be better to use a name like:
$wgSaveIPs
and have it default to true (the current state). Then set it to false if you don't want the IPs saved.
Mike
Am Mittwoch 27 Mai 2009 schrieb Michael Daly:
It's a bad idea to use a negative in a name. In English, it makes for confusing program statements with double negatives ( e.g. not don't save) It would be better to use a name like:
$wgSaveIPs
and have it default to true (the current state). Then set it to false if you don't want the IPs saved.
Sounds good, see attachment.
Hanno Böck wrote:
Attached is a patch to mediawiki that adds a new option $wgDontSaveIPs
What it does is allowing completely anonymous wikis by replacing the IP adress with 0.0.0.0.
(a bit background, there's a german campaign wirspeichernnicht.de, which wants to enforce a more anonymous web and provides a couple of descriptions how to disable ip saving in different apps - for mediawiki it tells to change the source, though I thought a clean option would be better: http://www.wirspeichernnicht.de/content/view/9/24/)
Attached patch is against mediawiki 1.15rc1. Would be nice if you would apply it.
I was thinking about this issue and I believe I have "the best of both worlds" solution, if someone is willing to code it. Take an IP address, concatenate it with a long string (salt), take its MD5 and use that as the anons' username. Two different IPs will have two different anon usernames, but for the readers it will not be possible to find out what is the original IP from the username.
Nikola Smolenski schrieb:
Hanno Böck wrote:
Attached is a patch to mediawiki that adds a new option $wgDontSaveIPs
What it does is allowing completely anonymous wikis by replacing the IP adress with 0.0.0.0.
(a bit background, there's a german campaign wirspeichernnicht.de, which wants to enforce a more anonymous web and provides a couple of descriptions how to disable ip saving in different apps - for mediawiki it tells to change the source, though I thought a clean option would be better: http://www.wirspeichernnicht.de/content/view/9/24/)
Attached patch is against mediawiki 1.15rc1. Would be nice if you would apply it.
I was thinking about this issue and I believe I have "the best of both worlds" solution, if someone is willing to code it. Take an IP address, concatenate it with a long string (salt), take its MD5 and use that as the anons' username. Two different IPs will have two different anon usernames, but for the readers it will not be possible to find out what is the original IP from the username.
To take this further: just add a hook point for munging the IP before it is stored. So plugins for different behavior can be written easily, and no new global config var is needed.
--- daniel
Am Mittwoch 27 Mai 2009 schrieb Nikola Smolenski:
I was thinking about this issue and I believe I have "the best of both worlds" solution, if someone is willing to code it. Take an IP address, concatenate it with a long string (salt), take its MD5 and use that as the anons' username. Two different IPs will have two different anon usernames, but for the readers it will not be possible to find out what is the original IP from the username.
If you have ideas how to implement this, I'd like to hear them, though this is not as trivial as it might seem.
This method only works if the salt is kept secret and changed regularly. I don't know how this could be implemented in a php app. If the salt is kept, the anonymity is not guaranteed - the range of IPs allows just calculating all of them with a given salt.
On Thu, May 28, 2009 at 6:31 PM, Hanno Böck hanno@hboeck.de wrote:
Sounds good, see attachment.
You can't send attachments to the mailing list. If i have opened a bugzilla report (#18981) [1], please attach the patch to that bug report following the standard [2].
[1]. https://bugzilla.wikimedia.org/show_bug.cgi?id=18981 [2]. http://www.mediawiki.org/wiki/How_to_become_a_MediaWiki_hacker#Posting_a_pat...
Hanno Böck wrote:
Am Mittwoch 27 Mai 2009 schrieb Nikola Smolenski:
I was thinking about this issue and I believe I have "the best of both worlds" solution, if someone is willing to code it. Take an IP address, concatenate it with a long string (salt), take its MD5 and use that as the anons' username. Two different IPs will have two different anon usernames, but for the readers it will not be possible to find out what is the original IP from the username.
This method only works if the salt is kept secret and changed regularly. I don't know how this could be implemented in a php app. If the salt is kept, the anonymity is not guaranteed - the range of IPs allows just calculating all of them with a given salt.
The salt must be unknown to users, of course. Site administrators may know it, but it is irrelevant since they can gather the same information from logs anyway.
Hello,
I moved to CentOS 5.3 to Fedora 10. I backuped my wiki database.
I reinstalled mysql and httpd. I copied the sql dump into the freshly created database. I moved LocalSettings.php, installed the Wiki and put back the LocalSettings.php in mediawiki/
I could not save any page. I get the message :
"Nous ne pouvons enregistrer votre modification à cause d’une perte d’informations concernant votre session."
which in English seems to be :
"**Sorry! We could not process your edit due to a loss of session data. Please try again. If it still doesn't work, try logging out and logging back in."
Could somebody help ?
Thanks Francois Colonna
"**Sorry! We could not process your edit due to a loss of session data. Please try again. If it still doesn't work, try logging out and logging back in."
It's probably a problem with your PHP sessions settings. Check where PHP is savings its sessions data (I think it's set in php.ini somewhere) and make sure the web server has write access there.
Le jeudi 28 mai 2009 à 15:19 +0100, Thomas Dalton a écrit :
"**Sorry! We could not process your edit due to a loss of session data. Please try again. If it still doesn't work, try logging out and logging back in."
It's probably a problem with your PHP sessions settings. Check where PHP is savings its sessions data (I think it's set in php.ini somewhere) and make sure the web server has write access there.
I looked at php.ini the file is
session.save_path = "/var/lib/php/session"
I set rights to drwxrwxrwx 2 root apache 4096 sept. 13 2008 session
I have still the same problem.
Thanks anyway. F. Colonna
Le jeudi 28 mai 2009 à 16:57 +0200, Frames Project a écrit :
Le jeudi 28 mai 2009 à 15:19 +0100, Thomas Dalton a écrit :
"**Sorry! We could not process your edit due to a loss of session data. Please try again. If it still doesn't work, try logging out and logging back in."
It's probably a problem with your PHP sessions settings. Check where PHP is savings its sessions data (I think it's set in php.ini somewhere) and make sure the web server has write access there.
I looked at php.ini the file is
session.save_path = "/var/lib/php/session"
Dear Thomas,
I found the reason of the problem : SELinux was activated (I did not pay attention to it)
In fact SELinux is sending a message and gives the solution. So I had to run
chcon -t httpd_sys_content_t /var/lib/php
to enable access to this session file for httpd
Thanks for putting me on the track towards /var/lib/php/session.
Best Francois Colonna
Maybe the problem is the time a session is saved. Take a look at session maxlifetime
At 11:57 PM 5/28/2009, you wrote:
Le jeudi 28 mai 2009 à 15:19 +0100, Thomas Dalton a écrit :
"**Sorry! We could not process your edit due to a loss of session data. Please try again. If it still doesn't work, try logging out and logging back in."
It's probably a problem with your PHP sessions settings. Check where PHP is savings its sessions data (I think it's set in php.ini somewhere) and make sure the web server has write access there.
I looked at php.ini the file is
session.save_path = "/var/lib/php/session"
I set rights to drwxrwxrwx 2 root apache 4096 sept. 13 2008 session
I have still the same problem.
Thanks anyway. F. Colonna
MediaWiki-l mailing list MediaWiki-l@lists.wikimedia.org https://lists.wikimedia.org/mailman/listinfo/mediawiki-l
_ _ (o) (o) oOOO----(_)----OOOo--- Henny (Lee Hae Kang) ----------------------------- http://www.henny-savenije.pe.kr Portal to all my sites http://www.hendrick-hamel.henny-savenije.pe.kr (in English) Feel free to discover Korea with Hendrick Hamel (1653-1666) http://www.hendrick-hamel.henny-savenije.pe.kr/indexk2.htm In Korean http://www.hendrick-hamel.henny-savenije.pe.kr/Dutch In Dutch http://www.vos.henny-savenije.pe.kr Frits Vos Article about Witsen and Eibokken and his first Korean-Dutch dictionary http://www.cartography.henny-savenije.pe.kr (in English) Korea through Western Cartographic eyes http://www.hwasong.henny-savenije.pe.kr Hwasong the fortress in Suwon http://www.oldKorea.henny-savenije.pe.kr Old Korea in pictures http://www.british.henny-savenije.pe.kr A British encounter in Pusan (1797) http://www.genealogy.henny-savenije.pe.kr/ Genealogy http://www.henny-savenije.pe.kr/phorum Bulletin board for Korean studies
How about putting on the Main_Page:
To edit anonymously, [[Special:Login..|login]] with User: anonymous Password: anonymous Editing with just your IP address has been disabled, to protect you.
Michael Daly michael.daly@kayakwiki.org writes:
Or the relatively common *nix approach of "guest" login.
Yeah, and also use $wgGroupPermissions['*']['edit']=false; to stop them from accidentally leaving their IP all over the place.
mediawiki-l@lists.wikimedia.org