[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, blacklisted website in body, repeated URL at end of long post: Royalty Skin Serum by Griffiralex on graphicdesign.SE
!!/test-a Our products ranges from high-power LED Ground Lights,LED corn bulb, LED Wall Lights, [LED panels][1],[LED chandelier][1],LED Spike Lights, LED Down lights, Flexible LED Strip Lights, LED Spotlights, LED Bulbs, and LED Tube Lights etc. Especially, our high power LED lights have been enjoying a very popular overseas market by the features of unique design, exquisite handwork, high quality and endurable, economical performance.
!!/test-a Ranpo Lighting Technology Co., Ltd, established in 2009, is a professional manufacturer and exporter who dedicates to research, manufacture and sales of LED lighting application products. Our factory(Sharp-Ray.,Ltd) located in Shenzhen City, Guangdong Province, China.
It was posted as a question. So I should probably have omitted -a. But I guess it does not make too much difference.
I'd normally suggest that we need to have positive detections, by using the !!/report function for that link; that way if it is spam we can see it in the posts list. In this case, though, I'm not entirely up for blocking that site until it's seen in at least two true-positive detection posts (even manual ones with large supporting "true positive" notes)
in my case I need to stab SmokeDetector code anyways.
I am not sure how to test that. Anyway, in case it would be useful, I have copied the body (markdown) of the spam post before it was deleted, so I can provide that if it helps in some way.
@MartinSleziak it's more or less parsed slightly differently when you see it as the raw data sent into MS from the API query, it returns HTML data IIRC.
[ SmokeDetector | MS ] URL-only title, bad keyword in body, bad keyword in title, link at end of body, pattern-matching website in body, +1 more: supplement4help.com/vlamorous/ by alican on askubuntu.com (@ThomasWard)
@ArtOfCode Any chance you could add Access-Control-Allow-Origin: * to the HTTP headers in DSS response to make it work with userscripts making cross-domain requests?
To /auth/token
At least... my research indicates that's what needs to be done.
@MartinSleziak You are not a privileged user. Please see the privileges wiki page for information on what privileges are and what is expected of privileged users.
@ArtOfCode DSS seems great for userscripts, since you can preserve access tokens across domains as long as you have a consistent way to generate a token uuid.
@ArtOfCode <appid>.<user's se network id> fits the bill for me, this particular userscript is only designed to work when the user is logged in to se anyways, so there will never be a case where the network id isn't available.
Then the key id remains constant across all se sites.
@Ferrybig Apps have an actual id that encapsulates both of those uniquely
Anyways I'm going to has the user's network id anyways but i have to salt it consistently, which is a problem
If I don't it's pretty trivial to request a different user's access token from dss (assuming you know they're using my app) and read some of their private profile data
[ SmokeDetector | MS ] Bad keyword in body, bad keyword in title, link following arrow in body, pattern-matching website in body: Chantelstclaire-serum/ by lottahman on graphicdesign.SE
[ SmokeDetector | MS ] URL in title, blacklisted website in body, blacklisted website in title, pattern-matching website in body, pattern-matching website in title, +1 more: healthyclubpro.com/peak-test-extreme/ by nega24 on graphicdesign.SE
