Marti Admin

You should probably fix this before it gets removed.

OUJS Admin


Re: @jesus2099:

Maybe it's because I'm behind a very big company proxy, where thousand of people may share the same IP.

Nope. The moment you hit the page it increments the count. Although that can be a valid case until TPM usage becomes more prevalent in node. Until then it could happen if someone else is hitting the exact same route in your intranet i.e. you will have bad actors in your company which everyone there is responsible for. The route uses your unique username so it shouldn't do that... unless you have a bad actor in your company.

The feature is working as expected, been thought out for several years, and has been thoroughly tested. It is also how the limiters have worked since at least #944. As I mentioned on development there may be some allowances later on however I (we) don't work, live, breathe 24 hours a day here.

The final questions for you are:

  1. Do you think it's responsible for making an assumption that it is not working/is broken?
  2. Do you think it's the responsible thing to not use development instead using production? You have demonstrated in the past with other issues that you know where it is. i.e. you've already opened prior issues on development... Why change now when we've continually mentioned use Development through out the years?
  3. Do you think it's responsible if there was actually a security bug like you are purporting that you would blare it to the whole world with an assumption or would it make more sense to be more discrete and methodical like every other project out there?
  4. Do you think having to take time out of everyone's busy schedule (including mine) to address an assumption is going to make things better?
    I'm open to questions and suggestions but never assume unless you are sure.

Had you not been one of our seasoned Authors you would have easily been eligible for removal. I am giving you a learned experience instead of applying that. It's not like the history of these changes are hidden from anyone and those changes are continually being manipulated by the bad actors currently and mostly on Chinese, Vietnamese, and Bangladesh server areas (i.e. we know exactly where they are doing their dirty work) however we have to leverage the good with the bad.

There are consequences to adding security, or we can just let it go and you'll lose your free hosting when the site goes offline like USO did. Which do you think is the better choice?

OUJS Admin


I let you in and you don't use Submit Code as Fork from Carrizo's script.

After a while you are eligible for removal for doing this.

OUJS Admin


Impact assessment

The following were the affected scripts rebuilt from the log:

Specifically the DB, which is the metadata for when it was published, when it was updated was impacted. AWS, which is the source code, is still present on AWS. However if your script is missing in your script list (That would be you @Temm ) then it will be orphaned until you upload it again.

  1. Any new users that signed up between that period were lost.
  2. Any changes to Script Info between that period were lost.
  3. Any changes to Profiles between that period were lost.
  4. etc.

OUJS Admin


Had some data loss in the production database. Lost the corrupted data between the hours of ~2021 12 23 03:03 to approximately 2021 12 23 12:00 UTC to be exact.

Major Apologies... at least we had a very recent backup.

Not sure what was wrong... even the core restore didn't work and had to drop the entire DB to restore... which is not normal.

Once again MAJOR APOLOGIES!

Please update your scripts if you did that between that period.

OUJS Admin



Re: @pbpublicvivaldi.net:

Could you please delete this thread?

He can't do that. Also you completely ignored the caution warning when you signed up, which has been there since July 9, 2014, and made the mistake that you need to live with.

Your attitude is poor and I might have considered editing the DB to your other typed in recently name (Starts with "p") however there are consequences for your ignoring warnings. So the only thing you should be aghast at is your inept action.

Apologies for the interruption @jscher2000

OUJS Admin


Re: @Patabugen:

presumably because the @source URL no longer works

@source has never been a part of updating and is specific to Tampermonkey (TM). See what it aliases to at TM and equates to an "upmix" of @homepageURL. In your case on your most recent update with the most installs that could be a value of https://openuserjs.org/scripts/Patabugen/Always_Remember_Me i.e. it is the homepage URL of the descriptive side of your presentation repository here on OUJS... but not the actual raw source Code itself. That is reserved for @updateURL and @downloadURL respectively. @updateURL is where it checks for an update, and @downloadURL is where it grabs the actual source if an update is available.

https://openuserjs.org/scripts/Patabugen/Always_Remember_Me/source

This is also okay (but not real helpful to your users) for @source since it has nothing to do with the updating system in the engines. It can be a visual display of the source Code but not the raw source Code.

// @source https://openuserjs.org/Patabugen/Always_Remember_Me.meta/source

This is just plain bugged and the route doesn't exist.

Does that mean that the ~1900 people with my script installed won't ever get another update without manually reinstalling?

If a Greasemonkey (GM) 3.x compatible engine is in a FAIL state then it is possible. I don't believe TM has the same issue but since he closed the source I'd have to go dig to find out for sure and deconstruct his code. As a safe bet for any .user.js engine always assume the "weakest" link which means possibly.

How can I work around this to push the updated @source URL so they continue to get updates?

See my previous reply and link. Not part of the update check and download source system.

The Author Tools, on each of your scripts, has been showing the usage of the updating system for quite some time (years or so) on what is "common" across all of the engines. i.e. you can select which type(s) (if available and mentioned from the FAQ) for both @updateURL and @downloadURL. Currently @downloadURL is optional but right now in lockdown @updateURL is not.

(as per a change in OpenUserJS I presume?)

Never been a change even before OUJS existed. @sizzle wrote the first updating back in the day with GM and @source has never been used. That is, again, reserved for the human side of the equation using HTML not .user.js.

So long explanation short... your misinterpretation of @source is possibly one cause (but not the only reason) of why we're in lockdown i.e. hopefully you understand the update check and download source keys better?

OUJS Admin




I have an idea that can be done for Gecko browsers too but can't do it until I get back to dev station to tweak for assisting more users.

Patience is always appreciated.

OUJS Admin


Starting to sound like a mynah bird here but...

I've done a work-around for Chromium based browsers to hopefully properly display their messages... however you might actually want to read the drop-down on the red install button which is normally blue for "make your own decision if it is safe to install". "Red (danger) is bad m'kay".

This script, among some other scripts on the site currently, won't be served when we are in lockdown until the Author makes a required change. You as a user may follow the https://openuserjs.org/about link as well for site status messages as documented.

Thanks for your attention,

OUJS Admin


Re: @micahrichards25gmail.com:

I've done a work-around for Chromium based browsers to hopefully properly display their messages... however you might actually want to read the drop-down on the red install button which is normally blue for "make your own decision if it is safe to install". "Red (danger) is bad m'kay".

This script, among some other scripts on the site currently, won't be served when we are in lockdown until the Author makes a required change. You as a user may follow the https://openuserjs.org/about link as well for site status messages as documented.

Thanks for your attention,

OUJS Admin


You dynamic loading of scripts shouldn't be happening.

You need to put those libraries under libraries and @require them instead into this script very quickly or removal is eligible.

OUJS Admin



Re: @Orphelius:

This script is obfuscated and is potentially dangerous. You should remove it immediately. It is also going away.

OUJS Admin


Re: @andrewstark853:

You have been content moderated for spamming. Please do no post external links trying to advocate for a particular product not related to Userscripts. This is the equivalent to signature spamming. If you do it again you will be eligible for removal especially since that's not normally the issue.

Re: @Anakunda:

Worked for me fine when you posted this a few days ago and just now. Yes there is rate limiting and yes you need to read the About pages that mentions it and not to mention Development. You hit the very high limit so don't do it again and it won't "clip" your installations.

If your browser has prefetching I would suggest turning it off as that will count against your limit.

OUJS Admin


Re: @kalbr_stoyn:

TOS Violation. You shouldn't be posting code in a comment without a reason written in text. Not to mention no markdown code fence.

Bye!




Yandex Browser with Protect v21.8.3 (Sep 27, 2021 Build 112) has "⋮ -> Settings -> Extension Catalog" which is where Violentmonkey (VM) and Tampermonkey (TM) get installed to for me at the moment. Last time I checked TM didn't install but now it does here.

Typically you go to the Chrome Store in Yandex Browser with Protect and install your choice of .user.js engine since Yandex browser is Chromium based. Only have one enabled at a time though.


Alright... try it now... did a work-around until I can dive into it much deeper to see what is tripping the server. Worked for me on development.

Thanks.
OUJS Admin


Hmmm this is a deep bug:

Error: aborted
    at connResetException (node:internal/errors:691:14)
    at TLSSocket.socketCloseListener (node:_http_client:407:19)
    at TLSSocket.emit (node:events:402:35)
    at TLSSocket.emit (node:domain:475:12)
    at node:net:672:12
    at TCP.done (node:_tls_wrap:580:7) {
  code: 'ECONNRESET'
}

... has to do with our request dependency and @icon validation. I just backed out latest node in development that I did and TM vulnerability check as well... no change.

Give me a little more time and I'll see if I can work-around it. Thanks for your patience.



You may have to logout of OUJS and GH and relogin to re-validate whatever https token is generated by the browser.

Not entirely sure what is going on there. The URL you mentioned works for me.