I spent most of three hours cleaning Wiki pages last night, going through the pages changed on 14th January, then starting on 13th January - then I looked at the volume of change, and realised that it would take a long time to finish the job. I had found and corrected about 120 pages, but there were many more changes on the 13th. So I thought first about what tool support might help me to fix the spam, then realised I should analyse the scale of the problem a bit more first. There are ~1821 pages on the Wiki, and ~1171 have been updated in January. An Anonymous Coward with IP address 87.248.161.196 changed at least 783 pages (I and others have probably corrected some of his/her work) between 14:18 and 13/01/2006 16:21 on 13th January. That''s more than one page every 10 seconds, on average. It''s not feasible for normal Wiki users to detect and correct this volume of change by hand. On the 14th someone posing as the Instiki Importer, but with IP address 82.131.14.155, made a smaller number of changes. I have reversed those (actually now I see I missed one on the 14th, and that there were a couple of changes from that address on the 12th). The spam I have seen is very uniform in its nature. Scanning for its signature and automatically rolling back the changes would be easy on the server side - it''s much slower and more laborious from the client. I have been tending to edit rather than roll back, as earlier versions turned out to contain spam in a large number of cases. Editing requires a little care - the div containing the spam links is usually right at the end of the useful content, but sometimes it isn''t, and sometimes it''s truncated. Some have !OK! in front of the div, and some don''t. In normal use, the Wiki appears to get of the order of 20 changes a day, from a variety of users. This is hard to see among the spam-adding and spam-removing traffic. Once the Wiki is clean, it might be reasonable to introduce a limit on the number of pages a given user could create or edit per hour. More intensive use might require privileges of some kind. Apart from the spam, the Wiki seems fragile and crude. For example the LighttpdConfig page was causing a Rails Application Error until I rearranged the <pre> and <code> tags to nest properly - and to get to an Edit page required manually typing in the URL to create a new version. The RailsAcademy, and the Tutorial pages are in a similar state). Page names and content don''t seem to be properly escaped (scroll down the All Pages list in IE to see what I mean). "Back in time" displays two copies of the earlier version. And the facilities of the wiki (search, xref, diff etc.) are weak compared with others. I don''t think it does Rails any credit to depend on such poor quality supporting tools - it just appears to be an extreme example of NIH. regards Justin
Hi Justin ~ The cleaning of the Wiki is appreciated by the entire community. Script.aculo.us recently had some much more obtrusive editing with entire articles being removed and replaced with gambling ads. They have implemented a verification field to slow down the input of the spam using their stikipad system. I know the Rails wiki is based on instiki, but after a quick glance it did not look like this is a current feature. I don''t think it would be too hard to implement. A strategy of stopping this at the source would obviously be preferred to manual clean up. Thx again, Ben On 1/15/06, Justin Forder <justin@j-m-f.demon.co.uk> wrote:> > I spent most of three hours cleaning Wiki pages last night, going > through the pages changed on 14th January, then starting on 13th January > - then I looked at the volume of change, and realised that it would take > a long time to finish the job. I had found and corrected about 120 > pages, but there were many more changes on the 13th. So I thought first > about what tool support might help me to fix the spam, then realised I > should analyse the scale of the problem a bit more first. > > There are ~1821 pages on the Wiki, and ~1171 have been updated in > January. An Anonymous Coward with IP address 87.248.161.196 changed at > least 783 pages (I and others have probably corrected some of his/her > work) between 14:18 and 13/01/2006 16:21 on 13th January. That''s more > than one page every 10 seconds, on average. It''s not feasible for normal > Wiki users to detect and correct this volume of change by hand. > > On the 14th someone posing as the Instiki Importer, but with IP address > 82.131.14.155, made a smaller number of changes. I have reversed those > (actually now I see I missed one on the 14th, and that there were a > couple of changes from that address on the 12th). > > The spam I have seen is very uniform in its nature. Scanning for its > signature and automatically rolling back the changes would be easy on > the server side - it''s much slower and more laborious from the client. I > have been tending to edit rather than roll back, as earlier versions > turned out to contain spam in a large number of cases. Editing requires > a little care - the div containing the spam links is usually right at > the end of the useful content, but sometimes it isn''t, and sometimes > it''s truncated. Some have !OK! in front of the div, and some don''t. > > In normal use, the Wiki appears to get of the order of 20 changes a day, > from a variety of users. This is hard to see among the spam-adding and > spam-removing traffic. Once the Wiki is clean, it might be reasonable to > introduce a limit on the number of pages a given user could create or > edit per hour. More intensive use might require privileges of some kind. > > Apart from the spam, the Wiki seems fragile and crude. For example the > LighttpdConfig page was causing a Rails Application Error until I > rearranged the <pre> and <code> tags to nest properly - and to get to an > Edit page required manually typing in the URL to create a new version. > The RailsAcademy, and the Tutorial pages are in a similar state). > Page names and content don''t seem to be properly escaped (scroll down > the All Pages list in IE to see what I mean). "Back in time" displays > two copies of the earlier version. And the facilities of the wiki > (search, xref, diff etc.) are weak compared with others. I don''t think > it does Rails any credit to depend on such poor quality supporting tools > - it just appears to be an extreme example of NIH. > > regards > > Justin > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >-- Ben Reubenstein benr@x-cr.com _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Ben Reubenstien wrote:> Hi Justin ~ > > The cleaning of the Wiki is appreciated by the entire community. > Script.aculo.us <http://Script.aculo.us> recently had some much more > obtrusive editing with entire articles being removed and replaced with > gambling ads. They have implemented a verification field to slow down > the input of the spam using their stikipad system. I know the Rails > wiki is based on instiki, but after a quick glance it did not look like > this is a current feature. I don''t think it would be too hard to > implement. A strategy of stopping this at the source would obviously be > preferred to manual clean up. >As a lurker, and sometimes commentor on this list, I 100% agree with Ben. I think the image based verification requires users to type in the generated text is a good solution for this. Zach
Ben Reubenstien wrote:> Hi Justin ~ > > The cleaning of the Wiki is appreciated by the entire community. > Script.aculo.us <http://Script.aculo.us> recently had some much more > obtrusive editing with entire articles being removed and replaced with > gambling ads. They have implemented a verification field to slow down > the input of the spam using their stikipad system. I know the Rails > wiki is based on instiki, but after a quick glance it did not look like > this is a current feature. I don''t think it would be too hard to > implement. A strategy of stopping this at the source would obviously be > preferred to manual clean up. > > Thx again,Ben, I can''t claim to have given any service to the community, because I only cleaned about 120 pages, and then found there were around 800 more (at least) that needed sorting out. It''s also the case that previous versions of the spammed pages contain spam. It would be good to have clean history, as well as clean pages. I''m coming round to the view that removing the spam through the normal Wiki interface is not the right approach - it just generates more versions on top of a corrupt history. regards Justin
Hi Justin, 120 pages is about a 120 times what I have done ;)... I agree though that manual cleanup from the client interface is a pain. I am ignorant as to who manages the wiki server, but I would be happy to help in any capacity to work on getting the verification step going to curb further spamming. I am going to also be evaluating StikiPad as soon as it is released. Maybe it presents a possible alternative. All of that aside the Wiki is an important part of the Rails community and it is where I found answers to many questions that I had. Keeping it free of spam and offering the most relevant information is key so I think you have raised a very important issue. ~ Ben On 1/16/06, Justin Forder <justin@j-m-f.demon.co.uk> wrote:> > Ben Reubenstien wrote: > > > Hi Justin ~ > > > > The cleaning of the Wiki is appreciated by the entire community. > > Script.aculo.us <http://Script.aculo.us> recently had some much more > > obtrusive editing with entire articles being removed and replaced with > > gambling ads. They have implemented a verification field to slow down > > the input of the spam using their stikipad system. I know the Rails > > wiki is based on instiki, but after a quick glance it did not look like > > this is a current feature. I don''t think it would be too hard to > > implement. A strategy of stopping this at the source would obviously be > > preferred to manual clean up. > > > > Thx again, > > Ben, I can''t claim to have given any service to the community, because I > only cleaned about 120 pages, and then found there were around 800 more > (at least) that needed sorting out. It''s also the case that previous > versions of the spammed pages contain spam. It would be good to have > clean history, as well as clean pages. > > I''m coming round to the view that removing the spam through the normal > Wiki interface is not the right approach - it just generates more > versions on top of a corrupt history. > > regards > > Justin >-- Ben Reubenstein benr@x-cr.com _______________________________________________ Rails-core mailing list Rails-core@lists.rubyonrails.org http://lists.rubyonrails.org/mailman/listinfo/rails-core
Justin Forder wrote:> There are ~1821 pages on the Wiki, and ~1171 have been updated in > January. An Anonymous Coward with IP address 87.248.161.196 changed at > least 783 pages (I and others have probably corrected some of his/her > work) between 14:18 and 16:21 on 13th January. That''s more > than one page every 10 seconds, on average. It''s not feasible for normal > Wiki users to detect and correct this volume of change by hand. > > On the 14th someone posing as the Instiki Importer, but with IP address > 82.131.14.155, made a smaller number of changes. I have reversed those > (actually now I see I missed one on the 14th, and that there were a > couple of changes from that address on the 12th).There are now 744 spammed pages out of 1835. The oldest is 10th January (it''s possible that there was spam before that which has now been removed). The spam is still coming, but slowly now. The spammer at IP address 82.131.14.155 has just changed from posing as Instiki Importer to posing as *me*! (This is the guy whose changes I reversed at the weekend.) For the record, any changes I make are from 217.169.11.194.> The spam I have seen is very uniform in its nature. Scanning for its > signature and automatically rolling back the changes would be easy on > the server side - it''s much slower and more laborious from the client. I > have been tending to edit rather than roll back, as earlier versions > turned out to contain spam in a large number of cases. Editing requires > a little care - the div containing the spam links is usually right at > the end of the useful content, but sometimes it isn''t, and sometimes > it''s truncated. Some have !OK! in front of the div, and some don''t.Spam signatures: 1) <div id="wiki1883" style="overflow:auto; height: 1px; "> This has all its URLs in the pp.ru domain, expressed like this: ![ innocent nude | http://innocent-nude.corp-option.pp.ru ] 2) !OK!<div style="overflow:auto; height: 1px; "> This has URLs in many different domains, expressed like this: <a href="http://www.u-blog.net/xzfat/">fat hairy ladies </a> Both share the style="overflow:auto; height: 1px; ", which is what I used to arrive at the figure of 744 spammed pages given above. There are 27 instances of <div id="wiki1883" - these have been coming back in the last couple of days after I removed nearly all of them at the weekend. The person placing these works slowly - a page a minute or slower. There are 728 instances of !OK! - some of these have already had the associated div removed. Some pages have both styles of spam. The !OK! guy works fast but hasn''t been active since the 13th. January.> the LighttpdConfig page was causing a Rails Application Error until I > rearranged the <pre> and <code> tags to nest properly - and to get to an > Edit page required manually typing in the URL to create a new version. > The RailsAcademy, and the Tutorial pages are in a similar state.Both the RailsAcademy and Tutorial pages came back to life after I took the spam out. I don''t think there are any broken pages left... but it would be good to get rid of pages with titles like: on%0D%0AContent-Type%3A+text%2Fplain%3B+charset%3D%22us-ascii%22%0D%0AMIME-Version%3A+1.0%0D%0AContent-Transfer-Encoding%3A+7bit%0D%0ASubject%3A+forenoon%2C+from+the+early+morning%2C+the+square%0D%0Abcc%3A+charleslegbe%40aol.com%0D%0A%0D%0Aa6499b8075b6f8f4da1e7ae3545f7f51%0D%0A. regards Justin
Justin Forder wrote:> Justin Forder wrote: > >> There are ~1821 pages on the Wiki, and ~1171 have been updated in >> January. An Anonymous Coward with IP address 87.248.161.196 changed at >> least 783 pages (I and others have probably corrected some of his/her >> work) between 14:18 and 16:21 on 13th January. That''s more than one >> page every 10 seconds, on average. It''s not feasible for normal Wiki >> users to detect and correct this volume of change by hand. >> >> On the 14th someone posing as the Instiki Importer, but with IP >> address 82.131.14.155, made a smaller number of changes. I have >> reversed those (actually now I see I missed one on the 14th, and that >> there were a couple of changes from that address on the 12th). > > > There are now 744 spammed pages out of 1835. The oldest is 10th January > (it''s possible that there was spam before that which has now been > removed). The spam is still coming, but slowly now. > > The spammer at IP address 82.131.14.155 has just changed from posing as > Instiki Importer to posing as *me*! (This is the guy whose changes I > reversed at the weekend.) > > For the record, any changes I make are from 217.169.11.194. > >> The spam I have seen is very uniform in its nature. Scanning for its >> signature and automatically rolling back the changes would be easy on >> the server side - it''s much slower and more laborious from the client. >> I have been tending to edit rather than roll back, as earlier versions >> turned out to contain spam in a large number of cases. Editing >> requires a little care - the div containing the spam links is usually >> right at the end of the useful content, but sometimes it isn''t, and >> sometimes it''s truncated. Some have !OK! in front of the div, and some >> don''t. > > > Spam signatures: > > 1) <div id="wiki1883" style="overflow:auto; height: 1px; "> > > This has all its URLs in the pp.ru domain, expressed like this: > ![ innocent nude | http://innocent-nude.corp-option.pp.ru ] > > 2) !OK!<div style="overflow:auto; height: 1px; "> > > This has URLs in many different domains, expressed like this: > <a href="http://www.u-blog.net/xzfat/">fat hairy ladies </a> > > Both share the style="overflow:auto; height: 1px; ", which is what I > used to arrive at the figure of 744 spammed pages given above. > There are 27 instances of <div id="wiki1883" - these have been coming > back in the last couple of days after I removed nearly all of them at > the weekend. The person placing these works slowly - a page a minute or > slower. > > There are 728 instances of !OK! - some of these have already had the > associated div removed. Some pages have both styles of spam. > > The !OK! guy works fast but hasn''t been active since the 13th. January. > >> the LighttpdConfig page was causing a Rails Application Error until I >> rearranged the <pre> and <code> tags to nest properly - and to get to >> an Edit page required manually typing in the URL to create a new >> version. The RailsAcademy, and the Tutorial pages are in a similar state. > > > Both the RailsAcademy and Tutorial pages came back to life after I took > the spam out. I don''t think there are any broken pages left... but it > would be good to get rid of pages with titles like: > > on%0D%0AContent-Type%3A+text%2Fplain%3B+charset%3D%22us-ascii%22%0D%0AMIME-Version%3A+1.0%0D%0AContent-Transfer-Encoding%3A+7bit%0D%0ASubject%3A+forenoon%2C+from+the+early+morning%2C+the+square%0D%0Abcc%3A+charleslegbe%40aol.com%0D%0A%0D%0Aa6499b8075b6f8f4da1e7ae3545f7f51%0D%0A. > >This is disheartening to read. I cannot imagine any person who would want to deface a community site like this, but nonetheless there are obviously people who don''t share the same standards. This definitely needs to be fixed. I know I mentioned that I like the number generated image that people have to type in, and for reasons that Justin pointed out in a private email it won''t work for 100% people and it doesn''t solve 100% of the issues. What other solutions could be done to fix this or severely slow this down? Zach
Justin Forder wrote:> There are now 744 spammed pages out of 1835. The oldest is 10th January > (it''s possible that there was spam before that which has now been > removed). The spam is still coming, but slowly now.I have cleaned those now. I used Watir to visit the Edit screen for every page, check the content for spam, and remove it if present. Before doing this for real, I downloaded the current markup from hundreds of spammed pages to test the detection/correction on. I tested the interaction with the Wiki in the sandbox first, then on a small number of pages, then gradually increasing numbers. Using Watir allowed me to watch the changes being made. By 11:45 GMT today all 1px-high divs and !OK! flags had been removed. I was driving this from the All Pages list, and it took an hour and a half (including small runs at first, and manual checking). A lot of the time was spent checking pages that contained no spam. In future it will be possible to run from the Recently Revised list, just covering the time since the previous run - this should only need a few minutes per day. There are a few pages that are uneditable, e.g. http://wiki.rubyonrails.com/rails/pages/MacOSX%3Ca+href%3D ...but they will be correspondingly unspammable. regards Justin
> I have cleaned those now. I used Watir to visit the Edit screen for > every page, check the content for spam, and remove it if present.If you can give us some regular expressions that you used with watir, we may be able to protect the wiki with mod_security. This will at least save us some grief while we look for a longer term solution. -- Cheers Koz
Michael Koziarski wrote:>> I have cleaned those now. I used Watir to visit the Edit screen for >> every page, check the content for spam, and remove it if present. > > If you can give us some regular expressions that you used with watir, > we may be able to protect the wiki with mod_security. This will at > least save us some grief while we look for a longer term solution.Thanks - I''ll send you those off-list. I''ve modified the Watir-based solution to work from the Recently Revised list, back to the time I last ran it... running it earlier today found 40 newly-spammed pages (and they are starting to impersonate my spam-eater - or maybe they just copy the previous updater''s name) While the pages were flashing by on Watir I saw some spam that didn''t match the patterns I''d picked up, so I am pressing on with something I had on my to do list - counting the URLs in each page. I''ll use this to look for new signatures. (Just got those results into a spreadsheet.) One spammer is still operating from 82.131.14.155 (34 changes yesterday). While in normal use the removal of Wiki pages is not recommended (as it would break bookmarks) this concern wouldn''t apply to pages that were created by spammers. (Also, empty pages wouldn''t be very valuable to bookmark.) Are you able to remove pages? If we can get the footprint of the Wiki down a bit it will become easier to manage and monitor. regards Justin
Justin Forder wrote:> I''ve modified the Watir-based > solution to work from the Recently Revised list, back to the time I last > ran it... running it earlier today found 40 newly-spammed pages (and > they are starting to impersonate my spam-eater - or maybe they just copy > the previous updater''s name) > > While the pages were flashing by on Watir I saw some spam that didn''t > match the patterns I''d picked up, so I am pressing on with something I > had on my to do list - counting the URLs in each page. I''ll use this to > look for new signatures. (Just got those results into a spreadsheet.)A new signature from yesterday: <u style="display:none;"> ... </u> sometimes with no semicolon after ''none'' 37 pages affected.> > One spammer is still operating from 82.131.14.155 (34 changes yesterday).He''s back on line right now. My last run will have removed some of his changes. regards Justin
If we''re getting such persistance from this ip can we just ban it? If the wiki is using the i2 code, I''d be happy to code up a patch to allow it. Kev On 1/19/06, Justin Forder <justin@j-m-f.demon.co.uk> wrote:> Justin Forder wrote: > > > I''ve modified the Watir-based > > solution to work from the Recently Revised list, back to the time I last > > ran it... running it earlier today found 40 newly-spammed pages (and > > they are starting to impersonate my spam-eater - or maybe they just copy > > the previous updater''s name) > > > > While the pages were flashing by on Watir I saw some spam that didn''t > > match the patterns I''d picked up, so I am pressing on with something I > > had on my to do list - counting the URLs in each page. I''ll use this to > > look for new signatures. (Just got those results into a spreadsheet.) > > A new signature from yesterday: > > <u style="display:none;"> > ... > </u> > > sometimes with no semicolon after ''none'' > > 37 pages affected. > > > > > One spammer is still operating from 82.131.14.155 (34 changes yesterday). > > He''s back on line right now. My last run will have removed some of his > changes. > > regards > > Justin > _______________________________________________ > Rails-core mailing list > Rails-core@lists.rubyonrails.org > http://lists.rubyonrails.org/mailman/listinfo/rails-core >
Justin Forder wrote:> A new signature from yesterday: > > <u style="display:none;"> > ... > </u> > > sometimes with no semicolon after ''none''Another spammer, another signature: <div style="display: none;"> from 82.200.208.98 with links to online pharmacies. 13 of those. 16 spammed pages from 85.202.154.230 I cleaned about 160 pages yesterday, mostly automatically, some by hand in the course of investigating new sources, and some by hand because they were hard to match reliably - specifically where the data pasted in was truncated, i.e. started with a <div> but ended in mid-URL, with no closing div and an incomplete <a> element. These break the displayed page - the Edit, Back in time etc. links don''t display (Firefox). Also some that had the links in plain view, with no enclosing HTML element - I haven''t tried matching those automatically yet. Counting URLs in the pages is working well - I shall extend this to looking at the delta between versions, and only counting external URLs. I want to start automatically rolling back, rather than editing out offending content, but this becomes tricky if the previous version is also spammed. A single level of rollback is not always enough. There is a fight going on over the contents of the RealWorldUsage page. It''s up to version 406 now, and it''s been through 20 or so versions in the last couple of days. Someone keeps replacing the content with a bunch of visible links to online pharmaceuticals, and others keep rolling back to the proper content. That''s all for now. Justin
Kevin Clark wrote:> If we''re getting such persistance from this ip can we just ban it? If > the wiki is using the i2 code, I''d be happy to code up a patch to > allow it.Blocking IP addresses should be straightforward at the Web server level. AFAIK the Wiki *is* running on i2 - can you tell me where to find the code? The "i2" link on the pages just points to the Instiki site. If you want to look at a patch for i2, I suggest the following: When a page change is submitted, look at the diff between this and the previous version (if this is a create, just looks at the submitted content). Focus on what has been added, and count the number of URLs to external sites. If this is over some configurable number, reject the change. The pages that have large numbers of legitimate links accumulate them slowly, so wouldn''t be hit by this. Doing the diff is important - otherwise a spammer could replace the content of (e.g.) the RealWorldUsage page with a similar number of spam links without being blocked. This wouldn''t protect against other kinds of malicious change, but would bring the frequency of changes down to a point where people could deal with it. One further suggestion - the Recently Revised list should include the IP address of the originator of the change. regards Justin
Clearing out on IP is actually pretty straight forward from the console. I just removed all from 82.131.14.155. Let''s keep this as somewhat of a permathread for now. Whenever you spot spam from a certain IP, we can clear that out and block the IP. -- David Heinemeier Hansson http://www.loudthinking.com -- Broadcasting Brain http://www.basecamphq.com -- Online project management http://www.backpackit.com -- Personal information manager http://www.rubyonrails.com -- Web-application framework
David Heinemeier Hansson wrote:> Clearing out on IP is actually pretty straight forward from the > console. I just removed all from 82.131.14.155. Let''s keep this as > somewhat of a permathread for now. Whenever you spot spam from a > certain IP, we can clear that out and block the IP.Everything I am doing would be much easier from the console, as I pointed out earlier. When you say you "removed all from 82.131.14.155", do you mean you destructively rewrote the history of the Wiki, or that you logically rolled back those changes (as a user could)? regards Justin
A quiet day yesterday. Four pages spammed by 72.9.230.2 with this pattern: <div id="new2" style="overflow:auto;height:1px;"> Visible links of this form ![ amateur free pic | http://amateur-free-pic.portrust.net.ru ] added to RailsWikiPageRecovery by 80.77.92.74 mod_ruby apammed by 209.100.183.225 with this pattern !OK!<div style="overflow:auto; height: 1px; "> I expect there were quite a few more cases caught by other people. - Justin
Spam yesterday:
There is another legitimate use of %r{display\s*:\s*none} in the
AssociationHelper page.
%r{height\s*:\s*1px} continues to be a good indicator of hidden spam.
Spam came from
62.87.166.43
72.9.230.2
82.77.137.102
82.131.14.155
85.98.50.252
210.71.187.53
210.95.78.93
Pages affected:
pages
RailsWebHosts
NamedRoutes
RailsWikiPageRecovery
GettingStartedWithRails
HowToMaintainSessionWhenCookiesAreNotAllowed
Tutorial
LocalizingDates
TextDrive
RailsWebHosts
BetterGeneratorsWish
RailsConf2006
HowtoInstallOnOSXTiger
StartAtTheBeginning
ControllerGenerator
I rolled these back by hand. In one case I had to go back four versions
to find a good one.
- Justin
22nd January 2006 ----------------- No spam? 23rd January 2006 ----------------- 82.131.14.155 spammed AbstractApplicationController <div id="wiki1883" style="overflow:auto; height: 1px; "> - rolled back (there were 9 versions!) 82.131.14.155 emptied AccessControlListExample - rolled back 85.202.152.48 spammed OfflineDocumentation <p style="display:none"> Bathroom furniture links! - rolled back Justin
After a quiet week some hidden spam has reappeared, using signatures
that I thought were being blocked:
<div style="overflow: auto; height: 1px;">
and
<u style="display:none">
Other people are catching most of the visible spam, but sometimes just
clear it out rather than rolling back to previous good content.
25th January 2006
-----------------
HowToReceiveEmailsWithActionMailer spammed by 218.153.140.70
visible links, original content deleted
- rolled back
homepage spammed by 218.153.140.70
visible links, original content deleted
- rolled back
addentry.php spammed by 62.171.194.9
visible link
- rolled back (several previous versions, not all from same source)
26th January 2006
-----------------
GettingStartedWithRails spammed by 61.182.66.53
visible links, original content deleted
- rolled back
HowToReceiveEmailsWithActionMailer spammed by 200.30.79.126
visible links, original content deleted
- rolled back
27th January 2006
-----------------
homepage spammed by 58.225.128.88
visible links, original content deleted
- had to go back ~15 versions to find a good one,
then I couldn''t roll it back
Tried three times but got the spam redisplayed each time.
The next day, someone else had removed all content,
leaving the page empty, I found that my changes had
gone in, but hadn''t been displayed to me at the time.
So there were three consecutive versions with my name on.
(Now there''s another, restoring the content.)
28th January 2006
-----------------
GettingStartedWithRails spammed by 211.222.109.222
visible links, original content deleted
- rolled back
LeeO cleared out by a well-meaning user:
previous version had been spammed by 67.18.98.36
- rolled back to good version
NamedRoutes spammed by 80.244.141.15
Hidden div:
<div style="overflow: auto; height: 1px;">
- rolled back
HowtoAddYourOwnConfigInfo spammed by 85.202.126.46
Hidden u:
<u style="display:none">
- rolled back
PostgreSQL spammed by 85.202.126.46
Hidden u:
<u style="display:none">
- rolled back
spam from 203.213.217.244
(visible links, original content deleted)
already cleaned up by 85.178.1.41
Other problems:
==============
1. In the All Pages list, the link
Berkeley DB/DB XML
gives
Not Found
The requested URL /rails/pages/Berkeley+DB/DB+XML was not found on this
server.
...looks like slashes in names aren''t being handled properly.
2. Many page versions give "Application error (Rails)"
e.g. http://wiki.rubyonrails.org/rails/pages/ActiveLDAP/versions/19
- Justin