Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 UTC on 18 March 2024, to get $100 off your ticket.
Trackbacks are a well-known spam target which anyone who have them enabled on their site unfiltered will know. It would be awesome if Mollom would plug into the TrackBack module and filter incoming trackbacks. I haven't played too much with it, but it might be possible using trackback.module's hook_trackback
.
Comment | File | Size | Author |
---|---|---|---|
#24 | mollom-245364.patch | 3.16 KB | Craig Gardner |
#22 | mollom-245364.patch | 2.71 KB | Craig Gardner |
#15 | 245364_mollom_trackback-15.d6.patch | 2.12 KB | Freso |
#2 | 245364_mollom_trackback-2.d6.patch | 1.23 KB | Freso |
#1 | 245364_mollom_trackback-1.d6.patch | 1.23 KB | Freso |
Comments
Comment #1
Freso CreditAttribution: Freso commentedI'm almost certain this won't work, but it's something to work with/from, no? :)
I'm not sure what the difference is with Trackback's 'receive' and 'insert'
$op
s, and I have no idea what is contained in$trackback
.Comment #2
Freso CreditAttribution: Freso commentedOops. Missed a semi colon. :x
Comment #3
allen074 CreditAttribution: allen074 commentedany chance for a 5.x version?!?!?!?! :)
Comment #4
Freso CreditAttribution: Freso commented@allen074: I'm mostly interested in a 6.x version, but once that is set, it shouldn't be too hard to backport it to 5.x (assuming trackback works the same in its 5.x branch). However, 6.x should be done first, so if you want to see this done for 5.x - please help me with 6.x.
Comment #5
allen074 CreditAttribution: allen074 commentedi wish i could help you freso - my coding is not that great :(
Comment #6
Freso CreditAttribution: Freso commented@allen074: Well, you could test the patch and tell me if it works. :) The handbook has an excellent page on applying patches. If you already have a site with both Trackback and Mollom that receives a lot of trackback spam, it should be quite easy to tell whether this patch makes Mollom check the Trackbacks. :)
Comment #7
Dries CreditAttribution: Dries commentedI don't know a thing about the trackback module, but I wonder how this patch is supposed to work:
The return value of the call to
mollom()
is not used.Comment #8
Freso CreditAttribution: Freso commentedHaha. You're right. But then, as I said: I'd be surprised if the patch works. I'll try and look into this, but I'm wary of just hacking in the blind (as I'll need two trackback enabled sites, where one of them will have to talk with Mollom - possibly corrupting data). Say, there's not a way to access a Mollom server (or a cluster or whatever) that doesn't share its data with the actual Mollom database?
Also, if you have any hints of which code in the Mollom module I need to look at or anything else, please let me know. I'll get back to this ASAP. (I'd also wish the Trackback module people would chime in here, but no luck so far.)
Comment #9
Ken Watts CreditAttribution: Ken Watts commentedThis is a golden opportunity for Mollom. About two years ago a patch appeared for trackback (in 4.7) that allowed akismet to filter trackbacks. Those who installed it were in heaven.
When Drupal 5.x came along, those of us who upgraded Drupal mostly ended up disabling trackback, because the patch was not incorporated into the next version, and none of the alternatives could hold a candle to the kind of automatic, smart filtering we had experienced with akismet.
There have been multiple feature requests going on now for over a year, both at akismet and trackback, requesting that one or the other reintroduce this capability, and neither module appears to have any interest.
If Mollom were able to filter trackbacks in Drupal, there would be many sites ready to implement it, so we could use trackback again.
I would be delighted to help test a patch, after it got to the stage where it was reasonably safe. Since my site is a working site, I can't risk corrupting data, etc. But once that risk is past, count me in.
Ken Watts
the daily mull
Comment #10
Freso CreditAttribution: Freso commentedSo, normally when a Trackback is submitted/made, the only user interaction there is, is the actual creation of the content that triggers the Trackback... right? If so, it'd be pretty hard to insert a CAPTCHA into the process. So I'm thinking, instead of a CAPTCHA, put it into moderation queue. Ie., if it is marked "spam", delete the Trackback on the spot; if it is marked "ham", save it and publicise it; if it is marked "unsure", put it in the moderation queue, and the site admin/moderator can mark it spam/ham (which will then also educate Mollom).
I know Mollom is supposed to remove the moderation queues, but if there is no user interaction for the user to enter a given CAPTCHA in the first place... what do you say? (Also, it will cut down on the moderation queue, as those that are clearly spam/ham will go straight through.)
Comment #11
Dries CreditAttribution: Dries commentedIt would not be possible to insert a CAPTCHA in the process. For now, the best thing to do would be:
1. If Mollom returns 'spam', block the trackback.
2. If Mollom returns 'unsure', put the trackback in moderation queue. (Is that possible?)
3. If Mollom returns 'ham', accept the trackback.
I don't know how the trackback module is implemented, but the above would work and might be easy to implement. Now, it is pretty important to implement a feedback mechanism, so that you can report trackbacks that were not properly classified by Mollom. That would be a requirement for such a patch going in.
Comment #12
Boris Mann CreditAttribution: Boris Mann commentedAnd this would be for the Pingback module, too (a cleaner "standard" for trackbacks, essentially).
As well, this really generalizes to *all* non interactive postings. FeedAPI is another example where we would LOVE to have anti-spam support from Mollom.
Aggregate feed --> create node --> pass to Mollom in non-interactive mode --> delete / moderate / or publish based on hammy-ness.
This particular patch only deals with comments -- I'd love for it (as per expanded title and my comments here) to handle nodes, too.
Comment #13
Freso CreditAttribution: Freso commented@ Boris Mann:
Please don't hijack the issue. Pingback works by inserting a comment, but Trackback uses its own type of content and thus API. This issue is for making Trackback and Mollom talk together. For Pingback to do what you describe, I think you should talk to the Pingback developers (which would be Andreas Haugstrup and, eh, me). (Also note, that since Pingback uses comments for its content, it already works with Mollom.)
@ Dries:
Yeah, of course there should be a way to educate Mollom. The goal is to remove the moderation queue, so... :)
Comment #14
Boris Mann CreditAttribution: Boris Mann commentedSorry, didn't mean to hijack, just that I think that a *general* use case would work here, rather than special casing for Trackback.
And, I assume it wouldn't work with Pingback, precisely because of the no-one-there-to-fill-out-captcha issue.
Comment #15
Freso CreditAttribution: Freso commentedAlright, time for bed. But I did make some progress, so uploading here so it won't accidentally get lost. :)
Comment #16
Ken Watts CreditAttribution: Ken Watts commentedI'm probably elucidating the obvious, but in the case of trackback, I would think that it's not so much a matter of eliminating the moderation queue as it is of minimizing its content.
It seems to me that the queue would be essential. When a trackback in the queue is deleted, a message should go to Mollom, marking it as spam, and when one is published a "ham" message should be sent.
I think you've already said that, between the lines, above. But I just wanted to be sure it was said... :)
Also, re: my offer to test above, I am still using 5.x, so for now it's an offer to test a 5.x version.
Ken Watts,
the daily mull
Comment #17
thePanz CreditAttribution: thePanz commented@Freso: I'm here for testing your trackback integration testing! I changed some lines of your patch (yes, changed CASE to SWITCH ;) )
Let me know!
Regards!
Comment #18
wretched sinner - saved by grace CreditAttribution: wretched sinner - saved by grace commentedsub to test when move to CNR
Comment #19
Ryanbach CreditAttribution: Ryanbach commentedSounds good!
Sub.
Comment #20
Ken Watts CreditAttribution: Ken Watts commentedWhere does this stand? Any progress? Anything I can do? Just wondering...
Comment #21
Freso CreditAttribution: Freso commented@ thePanz:
Haha. Well caught. ;)
@ Ken Watts:
I'm afraid I haven't had any time to do any more work on this since #15. :/ And per #16, I believe we are thinking about the same behaviour. And seeing how much time I've had for the 6.x version, I doubt I'll find any time at all to work on a 5.x one anytime soon. But it probably won't be too hard to backport.
Comment #22
Craig Gardner CreditAttribution: Craig Gardner commentedComment #23
Freso CreditAttribution: Freso commentedA few style errors, but looks good. :)
However, taking module weights into consideration - is it good to call
_trackback_operation()
inhook_trackback()
? Won't that make heavier modules unable to work with the trackback in question?Comment #24
Craig Gardner CreditAttribution: Craig Gardner commentedI looked it over again, and thought that you are right. Calling _trackback_operation is probably a little overkill for this, so I took it out and now have it "throwing" an error on spam.
I also noticed a little redundancy in the code that was there.
Let me know what you think now.
Comment #25
Dave ReidPostponing until #245682: Enable use of Mollom for any form and #412760: User interface brainstorming land.
Comment #26
Dave ReidComment #27
Oscar Illada CreditAttribution: Oscar Illada commentedI am wondering if any one have the solution for the integration with trackbacks, thanks alot.
Comment #28
henmue CreditAttribution: henmue commentedSubscribing. I got tons of trackback spam and no comfortable solution as mollom to fight it.
Comment #29
ScoutBaker CreditAttribution: ScoutBaker commentedPer the maintainer in #25, marking this back to Postponed.
Comment #30
Oscar Illada CreditAttribution: Oscar Illada commentedAnyone have news about this issue????
Comment #31
sunThis is a bit more complex, since no form is involved in the game. The new module code is all about forms, and there is no low-level functionality that would allow for programmatic validation of arbitrary content.
However, that's something we can consider to add. We would just have to make sure that the consumer provides as much data as possible + some required properties...
Alternatively, modules like Trackback could also programmatically execute a form (and optionally implement hook_mollom_form_info() to protect custom forms), which would work for textual analysis.
Comment #32
Ken Watts CreditAttribution: Ken Watts commentedIf I'm following the thread correctly, it seems like this request led to a very long discussion, which was finally postponed until a couple of other issues were addressed, but now they have been addressed.
If I'm right about that, wouldn't it be appropriate to make this request active again?
Thanks.
Comment #33
Ken Watts CreditAttribution: Ken Watts commentedComment #34
alippai CreditAttribution: alippai commentedsubscribe
Comment #35
Oscar Illada CreditAttribution: Oscar Illada commentedsubscribe
Comment #36
Wim LeersSubscribing.
Comment #37
corbacho CreditAttribution: corbacho commentedsubscribing
Comment #38
Oscar Illada CreditAttribution: Oscar Illada commentedAny progress???
Comment #39
gwynnebaer CreditAttribution: gwynnebaer commentedHow do we boot strap this item back into existence? Do I need to reroll this into D7 or ?? It was going well and then fell into weeds, but seems like there's momentum to resolve this or close it as a duplicate/etc. @sun or @dave_reid, can you comment?
Comment #40
sunThis issue is still on my radar.
However, as I've tried to clarify in #31 already, the main problem space is that the entire functionality of the module is currently architected around forms. If there is no form in the game, then the current Mollom module does not know how to process the "post".
As of now, you'd only be able to check a random data entity if 1) you know exactly how it is structured, 2) you're able to extract the necessary values from its data structure, and 3) you're able to translate those values into the format that the Mollom REST API expects. In other words, the only case for which you can do that currently is when you develop a custom integration for a very particular entity type.
Up until upcoming D8, Drupal did not provide the necessary architectural framework to allow Mollom to operate on raw entity objects. My hope is that the new Property/Field API in Drupal 8 will allow Mollom module to "make sense" of random entities, even when no form is involved. This new architecture should inherently allow the Mollom module to process entities on a programatic/API level.
In other words, I foresee a rather fundamental rewrite of the current Mollom module for the new architecture of Drupal 8 and I'm eager to start to work on that, but as there are some other hot topics on my plate currently, so it will take some time until I can get to that.
Comment #41
apadernoI am closing this issue, since Mollom (the service) reached its EOL and it isn't provided anymore.