-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
Hello,
I wanted to get an OK (or not) to return the page title, and timestamp for a given deleted revid. It might also be helpful to return the username. Some information on the tool is available at http://toolserver.org/~lifeguard/page/tools/get-deleted-data
This is needed as a workaround for bug 23489 (No way to get the page title of a deleted revision by its rev_id: https://bugzilla.wikimedia.org/show_bug.cgi?id=23489). Specifically, the database of link additions maintained by COIBot has some data corrupted by mixing charsets which needs to be repaired. We need page titles for corrupted rows, and since we have only a revid, we cannot get it from MediaWiki at present.
Thanks, - -Mike
Hello, At Sunday 08 August 2010 15:47:25 DaB. wrote:
I wanted to get an OK (or not) to return the page title, and timestamp for a given deleted revid. It might also be helpful to return the username.
in theorie that would be no problem as long as you would respect the ar_deleted-field. But in practice it is not that easy, because many revisions, which would oversighted today, were simply deleted in past (I guess enwp is similar to dewp here). So I can not allow such a webtool were you insert the rev_id and get the page_name back. But as far as I understand you, the main-usage for your webtool would be to fix a corrupt database for a bot; so why not just fix the database with data from the toolserver, without providing the data to the world (that would be ok for me)?
Sincerly, DaB.
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10-08-08 10:54 AM, DaB. wrote:
Hello, At Sunday 08 August 2010 15:47:25 DaB. wrote:
I wanted to get an OK (or not) to return the page title, and timestamp for a given deleted revid. It might also be helpful to return the username.
in theorie that would be no problem as long as you would respect the ar_deleted-field. But in practice it is not that easy, because many revisions, which would oversighted today, were simply deleted in past (I guess enwp is similar to dewp here). So I can not allow such a webtool were you insert the rev_id and get the page_name back. But as far as I understand you, the main-usage for your webtool would be to fix a corrupt database for a bot; so why not just fix the database with data from the toolserver, without providing the data to the world (that would be ok for me)?
Sincerly, DaB.
Well, it is useful information to be able to get for sysops... hence the bug report against MediaWiki. Hopefully the software will give such information directly - it is needed.
But in reality, I was asked to do it as a web tool, and it was just easier for me that way. The process needing information will be on another server, so a GET is obviously very simple to do. I'll look at other ways of accomplishing this if you insist.
- -Mike
How about requiring a password/code to go along with rev_id in order to use the tool (similar to the move to commons process?
Delta
On Sunday, August 8, 2010, Mike.lifeguard mike.lifeguard@gmail.com wrote:
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10-08-08 10:54 AM, DaB. wrote:
Hello, At Sunday 08 August 2010 15:47:25 DaB. wrote:
I wanted to get an OK (or not) to return the page title, and timestamp for a given deleted revid. It might also be helpful to return the username.
in theorie that would be no problem as long as you would respect the ar_deleted-field. But in practice it is not that easy, because many revisions, which would oversighted today, were simply deleted in past (I guess enwp is similar to dewp here). So I can not allow such a webtool were you insert the rev_id and get the page_name back. But as far as I understand you, the main-usage for your webtool would be to fix a corrupt database for a bot; so why not just fix the database with data from the toolserver, without providing the data to the world (that would be ok for me)?
Sincerly, DaB.
Well, it is useful information to be able to get for sysops... hence the bug report against MediaWiki. Hopefully the software will give such information directly - it is needed.
But in reality, I was asked to do it as a web tool, and it was just easier for me that way. The process needing information will be on another server, so a GET is obviously very simple to do. I'll look at other ways of accomplishing this if you insist.
- -Mike
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.10 (GNU/Linux)
iEYEARECAAYFAkxev4kACgkQst0AR/DaKHufWACfaSvwrmDuhvwe1h3wfTSUcBaD VcgAoLagCyB0lZ/oC7XJFqMaeOrrFEFw =J2NE -----END PGP SIGNATURE-----
Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10-08-08 04:02 PM, John Doe wrote:
How about requiring a password/code to go along with rev_id in order to use the tool (similar to the move to commons process?
Delta
Yes, I suppose that's possible. Can we use Basic or Digest auth to protect parts of our web space? I suppose the tool itself could do authentication, I'd have to learn how...
- -Mike
Perhaps you could use the TUSC to auth users, has the advantage that people already use it and allows people to link their wp account to it. (http://toolserver.org/~magnus/tusc.php)
Just a thought.
-Brett
-----Original Message----- From: toolserver-l-bounces@lists.wikimedia.org [mailto:toolserver-l-bounces@lists.wikimedia.org] On Behalf Of Mike.lifeguard Sent: Monday, 9 August 2010 12:14 PM To: toolserver-l@lists.wikimedia.org Subject: Re: [Toolserver-l] Exposing data about deleted revisions
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10-08-08 04:02 PM, John Doe wrote:
How about requiring a password/code to go along with rev_id in order to use the tool (similar to the move to commons process?
Delta
Yes, I suppose that's possible. Can we use Basic or Digest auth to protect parts of our web space? I suppose the tool itself could do authentication, I'd have to learn how...
- -Mike
_______________________________________________ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
Mike.lifeguard wrote:
On 10-08-08 04:02 PM, John Doe wrote:
How about requiring a password/code to go along with rev_id in order to use the tool (similar to the move to commons process?
Delta
Yes, I suppose that's possible. Can we use Basic or Digest auth to protect parts of our web space? I suppose the tool itself could do authentication, I'd have to learn how...
-Mike
That's quite easy. You are only giving access to one process (the db repairing tool).
So that can be done with a simple line at the top: if ($_GET['pass'] != 'mysupersecretpassword') die (1);
(assuming php, it's similar for other languages)
On Mon, Aug 9, 2010 at 4:28 PM, Platonides platonides@gmail.com wrote:
So that can be done with a simple line at the top: if ($_GET['pass'] != 'mysupersecretpassword') die (1);
It's maybe not the best idea to authenticate using get (hint: the super secret password is stored in web server logs (I'm not sure but I think they are (partially?) available to public)).
A better approach would be to use HTTP-authentication or cookie-based authentication (or at least a post request).
On 8/11/10, Michael Rosenthal rosenthal3000@googlemail.com wrote:
It's maybe not the best idea to authenticate using get (hint: the super secret password is stored in web server logs (I'm not sure but I think they are (partially?) available to public)).
It seems that all people who have access to the logs also have access to the db table.
That may be so, but lets keep to best practices shall we just incase that ever changes down the track.
-Brett
-----Original Message----- From: toolserver-l-bounces@lists.wikimedia.org [mailto:toolserver-l-bounces@lists.wikimedia.org] On Behalf Of Liangent Sent: Wednesday, 11 August 2010 3:02 AM To: toolserver-l@lists.wikimedia.org Subject: Re: [Toolserver-l] Exposing data about deleted revisions
On 8/11/10, Michael Rosenthal rosenthal3000@googlemail.com wrote:
It's maybe not the best idea to authenticate using get (hint: the super secret password is stored in web server logs (I'm not sure but I think they are (partially?) available to public)).
It seems that all people who have access to the logs also have access to the db table.
_______________________________________________ Toolserver-l mailing list (Toolserver-l@lists.wikimedia.org) https://lists.wikimedia.org/mailman/listinfo/toolserver-l Posting guidelines for this list: https://wiki.toolserver.org/view/Mailing_list_etiquette
On 09/08/10 12:43, Mike.lifeguard wrote:
On 10-08-08 04:02 PM, John Doe wrote:
How about requiring a password/code to go along with rev_id in order to use the tool (similar to the move to commons process?
Delta
Yes, I suppose that's possible. Can we use Basic or Digest auth to protect parts of our web space? I suppose the tool itself could do authentication, I'd have to learn how...
*.toolserver.org is most likely full of XSS vulnerabilities. It doesn't matter what sort of authentication you use, it's pointless if anyone can run arbitrary client-side scripts on it via XSS. I don't think any private data should be delivered on this domain at all. And I don't think authenticated write operations should be there either.
-- Tim Starling
Tim Starling wrote:
*.toolserver.org is most likely full of XSS vulnerabilities. It doesn't matter what sort of authentication you use, it's pointless if anyone can run arbitrary client-side scripts on it via XSS. I don't think any private data should be delivered on this domain at all. And I don't think authenticated write operations should be there either.
What does "authenticated write operations" mean in context?
MZMcBride
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1
On 10-08-11 02:11 AM, Tim Starling wrote:
*.toolserver.org is most likely full of XSS vulnerabilities.
You're very probably right - Dispenser has been looking for them in the past few days, and I don't think they had much difficulty doing so.
I don't think any private data should be delivered on this domain at all.
Well, we're asking to have this exposed in the UI and/or API. It happens to be "private" because nobody bothered to make it available - not because it falls under the definition of "private data" we use in the privacy policy, for example.
That said, until it /is/ made available in the API or UI, I'll certainly respect the rules regarding making such data available.
- -Mike
toolserver-l@lists.wikimedia.org