Back to original GH clone... reinstalled all deps again from scratch... and it's letting me in. :\

Am able to log in now.

Re: @xenofungi:

As for the GM_addStyle, I still can't get it working in firefox.

Possibly because you left the @grant none in? That line usually overrides any other grants if present.

You've had over a month to fix this and a few weeks since the last reply. Applying the TOS default action. Bye.

Re: @discon:

Should read about CC0 here... still not acceptable.

Thanks.

Greasemonkey Port 3.9.0.1rc1pre-sm.xpi is available now at the SF file repo.

Thank you. :)

OUJS Admin

Please reread about OSI Approved only licensing here.

You have a very short period to correct this before you and your script are eligible for removal.

Please remedy ASAP and thank you for your cooperation.

OUJS Admin

Btw you seem to have this issue on your other 3 scripts.

Thanks for attending to this as soon as possible.
OUJS Admin

Please reread about Public Domain here.

OUJS Admin

Re: @Vadorequest:

Vadorrequest/fb-adblock-timeline#3

Working for me within the attack prevention guidelines set in place. e.g. It would seem that your TM is still majorly flawed with hitting the install route more than once possibly with the script updater routines.

See also #957.

Re: @shush:

Appreciate you giving it a try.

So I have a question... looking at http://www.shush.se/index.php?extension and the settings for http://www.shush.se/index.php?settings with "Force Extension" are these two related to the same thing? e.g. is the site itself trying to hotlink in this Userscript when enabled ??

Completed... ~18 minutes offline to do the snapshot.

Re: @shush:

keep in mind this script has been on here long before the fiasco started (unchanged)

TM has had an issue with caching and pulling full script source going back to Userscripts.org days from many years before this script was published here. When it was first determined with usoCheckup, and AAU from @sizzle, we added in caching headers at that time to attempt to control it via the browser... some of it is Chromium/Chrome too. So if anyone isn't up to date then there is a higher chance of multiple site hits happening. Adding some simple precautions to a known script that continually hits OUJS would be a wise thing to do. We've blocked brute force attacks for every Userscript as our precaution.

however there are no iframes used anywhere and the player simply will not load in an iframe.

Just wrote an ancillary .user.js and a brief extension to make it load in an iframe and it works well... but natively the player loader script attempts to redirects out of a framed element when possible. The framing also does not have to include the Flash player and your current @match will inject into those frames as well. If the .user.js engine is flawed then your script will be pulled from OUJS x number of frames times.

and is completely independent

If a system/platform has been compromised in any way this is not true... better to be precautious with some simple checks. That's why @noframes exists in the first place besides easing up some common coding. You can't guarantee that your script is the only one running on this @matched site and you can't guarantee that shush.se doesn't have some live option that injects framing on the fly.

If you want a more accurate raw install count I would suggest reading this. This will cover up publicly if there is a .user.js engine issue but we'll still be able to track when needed especially with our brute force prevention.

Time for another backup... should be about 20 minutes later this evening the 24th of July, 2016.

Re: @shush:

The traffic spikes on the weekends. Monday and Tuesday it spikes as well.

It spikes constantly every day of the week... the raw installs of this script are the counts up top here on OUJS. Provided @sizzle gets back to me on moving the install stats to once daily per IP based and locally on the VPS all of these numbers would be invalidated... however raw installs shows how many times someone is accessing the .user.js URL portion of any script. We are currently curtailing this with the brute force prevention mentioned by @visionsofleo and some others.

the player already has an iframe breaker

There currently is no window.top reference in this .user.js so if your @match is too wide (inclusive) and multiple iframes/frames exist on the site that too can "inject" the script in multiple locations. In tandem with a .user.js engine flaw (most likely Tampermonkey as the retry routine was incorrectly and badly "borrowed" from usoCheckup and too aggressive). Since derjanb hasn't been communicative lately about his meta check routine I can only presume that he hasn't spent any time on it. I am rarely in Chromium/Chrome so I haven't retested this since that issue report.

this should isolate the issue to tampermonkey

Pointing the finger at that engine might still be the main issue however I still think that your script could use some tender loving care (TLC). I didn't remove it back in April when the fiasco started/continued with Tampermonkey (TM)... but as you may have noticed I put in the @updateURL and version bumped to maintain the integrity of OUJS... otherwise it would have been deleted (not removed) until the situation with TM calmed down a bit. Your script was and still is the number one "raw installed" here on OUJS and it's not just a matter of popularity as some engine somewhere on some client(s) is pulling source every page load/document start (or worse every iframe/frame) load.

My point to you is that you do not have a frame check in this script and most likely there is something that you can do to improve your users experience with it. Personally I would start off with a @noframes and even put the window.top check in for older engines that don't support @noframes in the UserScript metadata block... since you know how your script works better than anyone else with these "certain videos" you can tell if it's still working with the current @match values... or if those keys needs to be refined a bit.

Re: @shush:

What do you mean by "constantly hit the site"?

This script and a couple of others is a portion of the reason why the 429 is in place on OUJS. As I mentioned in the similar report @noframes, if supported in the .user.js engine, might help... if not a window.top check can achieve the same thing.

It is completely independent after installed. If it constantly hits the site that's an issue with tampermonkey.

There was (still might be) an issue with Tampermonkey which is the other portion of reasoning for the 429 check. The number of raw installs on this script reflects that something on the site is triggering reinstalls. Excluding popularity of this script it has gone up approximately 20 installs (1791262 to 1791281) just in the time that it's taken me to type this up. So something is up... perhaps the site is also refreshing the window constantly which in tandem with a .user.js engine flaw could really be increasing the traffic.

Re: @visionsofleo:

Until the author comes back I seriously doubt this script is viable. You may want to try a few things and report back what works with tweaking it... or fork it with this sites forking capabilities with a model that doesn't constantly hit the site. As I don't visit this site I can't tell you why it constantly polls OUJS. I can only guess it is getting triggered while watching a video... but that's just a guess.

Ref:

• Similar report to 429 cant install.

Re: @dmitri22:

(Russian translation courtesy of Microsoft Bing Translator):

Good afternoon
Tell me what to do with this script, install fails, issues an error on line @match.

With glob pattern matching @match should include ://.

So the line of:

// @match *guvm.mvd.ru/services/appointment

... at minimum needs to be written as...

// @match *://guvm.mvd.ru/services/appointment

... according to those specifications.

See also:

• https://developer.chrome.com/extensions/match_patterns

(Russian translation courtesy of Microsoft Bing Translator):

С glob шаблоны @match должна включать ://.

Таким образом линии:

// @match *guvm.mvd.ru/services/appointment

> ... на минимум должны быть написаны как...

> ``` js
// @match *://guvm.mvd.ru/services/appointment

... по словам этих спецификаций.

Смотрите также:

• https://developer.chrome.com/extensions/match_patterns ʳᵘ⁻ᴿᵁ

Re: @ted90:

Thanks... but if we see signature spam again that has no relation to UserScripts your account will be eligible for removal. Please do not do this a third time. Please re-read the TOS link at the bottom of every page... it is quite clear.

Besides the fact that you've abstracted this a lot, which is usually unnecessary for FOSS scripts, you need to describe what you are doing to potential end users in your content area including exposing them to a third party ad system. e.g. a privacy invasion.

Target code:

    window.google_ad_client = "ca-pub-5878021809689194";
    window.google_ad_slot = "1479874665";

do openuserjs checks the updateURL from time to time and updates stored version of a script?

OUJS doesn't do anything like that... however the .user.js engine does. e.g. Greasemonkey and others.

concrete example:

• (1.0.1) https://openuserjs.org/scripts/solygen/show link to trakt.tv (based on IMDB2Trakt from Arias)
• (2.0.0, updateURL) https://rawgithub.com/solygen/userscripts/master/scripts/imdb.com/link-to-trakt.user.js

As you may have already figured out you posted two scripts with two different @names... when you changed the @name it will install a 2nd script as per .user.js engine specifications. We currently mirror that functionality with our URLs.

If this not happening automatically can i trigger it manually?

Assuming an end user has script updating enabled then bump your @version. Again this is all in the .user.js engines.

Re: @simg:

Is there a unminfied source of it somewhere where I can run it through some GM tests? (e.g. home SCM instead of cloudflare CDN) e.g. I'd like to have more than just a, b, c like for the variable names for a clearer human readable experience.

Re: @ome3n:

No worries. The creator of the issue should be able to close it up top and so can @ifugu . :) I usually prefer not to do this with elevated privi's unless it's absolutely necessary.