Decide the fate of custom site/project prefixing in the UserScript metadata block #285
Comments
Martii
changed the title
|
Or manage stuff like collaboration on the website itself. I say we axe it. |
* Show a modified parseMeta routine for `:` padding support **NOTE** This alpha version pulls full script source and won't be in user.js release Applies to: * OpenUserJS/OpenUserJS.org#285
That is only a small piece of it. Moving collaboration to group structure doesn't address any other site specific metadata block(s) options... see the updated refs section above. The reason I made the request on userscripts.org (USO) for I've already done a certain amount of the necessary migration routines depending on what way we all decide to go with site/project prefix options. See an additional marked EDIT(s) above too. |
|
@Zren has a good point. If someone writes a malicious script and tag it as authored by Martii and publish it, that's not a good reason for him to get falsely accredited as that script's author. |
This is #208 from above. It's easy enough to check if the user exists (which is why at least the collaborators are hyperlinked and there are already some safeguards in place) and check if the script exists under that users One could also use someone elses We'll work on that soon but I think until then the fate of any site specific key needs to be determined in the standard metadata block... if "GM/GMP/TM/VM/anyone else" are going to be mutually collaborative or optionally collaborative... e.g. Do we hear that the user.js engines don't care about anyone else or are they willing to listen to common ideas. I appreciate your input though as I know you have gone between Scriptish and GM in the past and definitely beneficial to the community as a whole. Me personally, I'm leaning towards the separate metadata block for our site to prevent any future conflicts and from what everyone else has been typing... but am looking for alternatives. If another user.js engine or another site wants to pick up on it then that is great. Cave monkeys beware of evolution! ;) :) |
* Show a modified parseMeta routine for multiple metadata blocks **NOTE** This alpha version pulls full script source and won't be in user.js release Applies to: * OpenUserJS/OpenUserJS.org#285
|
bump There's some options to decide in here that I've been waiting for some response in here. After some wait time with Zren and his efforts and some tinkering with the alpha some more most likely this is going to be tackled. |
|
Still awaiting... there are two trains of thought over the past few months... keep |
Martii
changed the title
* TODO: Needs further diagnosis in real-time and eventually permanently fixed on completion of OpenUserJS#285 * [oujs - Meta View](https://openuserjs.org/scripts/Marti/oujs_-_Meta_View) **not** exhibiting this behavior... so appears to be a difference in current V8 *node* versus browser JavaScript parse * Not sure when this occurred as there are scripts uploaded currently that utilizes the localizations of `@description` and `@name` but is responsible for some of the server restarts
Misc note(s): * `$ git checkout greasemonkey/greasemonkey/master peg.txt` after remote is added temporarily Applies to OpenUserJS#285
* *pegjs* files are technically models just not DB oriented much like our settings.json files are. Can move on refactoring if needed. Applies to OpenUserJS#285
* Further cleanup will be needed before implemented hopefully later this weekend Applies to OpenUserJS#285
* This allows the browser to view these instead of downloading * May also prevent some warnings from security sites * Using generic JavaScript MIME type as that is what my editor is saying it is on auto-detect... PEG.js is very closely related to JavaScript so should be okay. Applies to OpenUserJS#285
|
Bingo... figured out the migration routine issue... all metadata is (should be) correct on production (save for the Graveyard still)... been doing this issue too long with too many variants of the code. :) |
* End focusing on peg and restore half/half viewing * Stop simulating the OpenUserJS metadata block since OUJS has support natively from OpenUserJS/OpenUserJS.org#285 via OpenUserJS/OpenUserJS.org#717 **NOTE** This will need some tweaking to dynamically handle any other blocks we may add for other sites should they choose to evolve this route just like OUJS is set up to do.
"extremely lazy" (for me at least) means that the old meta objects were transformed into the new meta objects unlike what I did with production (active) scripts which the meta was regenerated from script source. Btw GH is sooooooooooooooooper slow right now. :\ |
|
@sizzlemctwizzle Closure!!! :) |
|
Closed by #717 and the plethora of comments here. |
Add *pegjs* to the dispersed Applies to #285
* Fix grammar rule that used to work in 0.8.0 to work with 0.9.0 ... this was my bad too * Knew `var` was going to be needed at some point with `upmix` as I thought it was a little peculiar in *pegjs* grammar * Retested both grammars at http://pegjs.org/online ... should be a bit faster now that it alleges strict mode for that project * Update *jwt-simple*... only code change is an exception trap for lack of token Some post OpenUserJS#285 fixes with/and upward migration
|
Reopened due to #729 |
|
As previously announced yesterday... taking server offline for migration hump... see everyone on the other side. :) |
|
Back online... revalidating... on current master commit on production. |
|
Graveyard is not complete yet... so leaving open until I get this done... this is a bit more complicated due to mongoose requirements of sub-Objects and the virtual "reason" I put in with |
|
Graveyard should be complete.... also zapped that final script without source on sizzles account (This particluar issue was possibly somewhere around #633 based off most of the dates I skimmed over... don't know for sure). Closing as redone. |
Post followup for OpenUserJS#718 and OpenUserJS#285
* This has resurfaced with another Author misunderstanding collaboration and potentially opening up a security hole with their script being edited by others. So at least we can check to see if the account(s) currently exists. They are still responsible for any unauthorized edits if they type the incorrect existing username. * Also fixes a feature with unhandled casing... probably best to leave it exact unlike URLs to user homepages. Really don't need different casings floating around in these labels i.e. symmetry. Post OpenUserJS#285
* This has resurfaced with another Author misunderstanding collaboration and potentially opening up a security hole with their script being edited by others. So at least we can check to see if the account(s) currently exists. They are still responsible for any unauthorized edits if they type the incorrect existing username. * Also fixes a feature with unhandled casing... probably best to leave it exact unlike URLs to user homepages. Really don't need different casings floating around in these labels i.e. symmetry. Post #285 Auto-merge
In relation to greasemonkey/greasemonkey#1963 I see 3 possibilities so far over the past few days to address an impending conflict with everyones project.
or
or
This entails extra coding to maintain the
:because we won't always know if a key is a site prefix or a locale... so must pad using an extra:. Padding will need to be maintained.Everyone, especially the maintainers at @arantius @johan @gera2ld @derjanb @OpenUserJs/admin @OpenUserJs/owners @OpenUserJs/backend @OpenUserJs/frontend and @JasonBarnabe, is welcome to participate in this team effort meta discussion as usual.
Please let me know if any other ideas are better, worse, ineffective, etc. :)
Refs:
@oujs:authorto match current username #208subject to changefor site/project prefixes. #284The text was updated successfully, but these errors were encountered: