Skip to content

Script Name Casing Duplicates #656

Closed
#658
Closed
Script Name Casing Duplicates#656
#658
Labels
bugYou've guessed it... this means a bug is reported.securityUsually relates to something critical.
Milestone
#486

Description

@TimidScript
TimidScript
opened on Jul 2, 2015

If you change the casing of your script name you are unable to access latest version.

Steps I took and the bug it created.

I had a script name with the word "deviantART" I changed it to "DeviantArt" and updated the version from 1.0.5 to 1.0.6. In the script listing the name remains "deviantArt", but the version is 1.0.6. When you try and install or look the code, it points to 1.0.5. I fixed it by updating the script again but with the old casing "deviantArt". There might be a script floating around in the database with the name "DeviantArt", that's not deleted.

(Making the user and script name as the UID causes some painful limitations to the script author. On top breaking auto-update, the install counter resets.)

Activity

  1. Martii
    added this to the #486 milestone on Jul 2, 2015

  2. Martii commented on Jul 2, 2015

    @Martii
    Martii
    on Jul 2, 2015
    Member

    This is more or less a duplicate but important enough to keep tracking as an individual issue as a watch point with the parent milestone. Thanks for the report.

  3. Martii
    changed the title [-]Bug - Script Name Casing[/-] [+]Script Name Casing[/+] on Jul 2, 2015

  4. sizzlemctwizzle commented on Jul 2, 2015

    @sizzlemctwizzle
    sizzlemctwizzle
    on Jul 2, 2015
    Member

    We identify scripts by @name and @namespace, which are both case-sensitive.
    You created a new script when you changed the name. Even Greasemonkey would
    have recognized it as a different script with the name change.
    On Jul 2, 2015 8:56 AM, "TimidScript" notifications@github.com wrote:

    If you change the casing of your script name you are unable to access
    latest version.

    Steps I took and the bug it created.

    I had a script name with the word "deviantART" I changed it to
    "DeviantArt" and updated the version from 1.0.5 to 1.0.6. In the script
    listing the name remains "deviantArt", but the version is 1.0.6. When you
    try and install or look the code, it points to 1.0.5. I fixed it by
    changing the updating the script again but with the old casing
    "deviantArt". There might be a script floating around in the database with
    the name "DeviantArt", that's not deleted.

    Making the user and script name as the UID causes some painful limitations
    to the script author. On top breaking auto-update, the install counter
    resets.

    —
    Reply to this email directly or view it on GitHub
    #656.

  5. sizzlemctwizzle commented on Jul 2, 2015

    @sizzlemctwizzle
    sizzlemctwizzle
    on Jul 2, 2015
    Member

    However this bug might be the result of case-insensitivity in the actual
    URL.
    On Jul 2, 2015 3:30 PM, "Michael Medley" medleymind@gmail.com wrote:

    We identify scripts by @name and @namespace, which are both
    case-sensitive. You created a new script when you changed the name. Even
    Greasemonkey would have recognized it as a different script with the name
    change.
    On Jul 2, 2015 8:56 AM, "TimidScript" notifications@github.com wrote:

    If you change the casing of your script name you are unable to access
    latest version.

    Steps I took and the bug it created.

    I had a script name with the word "deviantART" I changed it to
    "DeviantArt" and updated the version from 1.0.5 to 1.0.6. In the script
    listing the name remains "deviantArt", but the version is 1.0.6. When you
    try and install or look the code, it points to 1.0.5. I fixed it by
    changing the updating the script again but with the old casing
    "deviantArt". There might be a script floating around in the database with
    the name "DeviantArt", that's not deleted.

    Making the user and script name as the UID causes some painful
    limitations to the script author. On top breaking auto-update, the install
    counter resets.

    —
    Reply to this email directly or view it on GitHub
    #656.

  6. Martii commented on Jul 2, 2015

    @Martii
    Martii
    on Jul 2, 2015
    Member

    which are both case-sensitive

    Yup... and when we move to _id we'll need to watch that someone doesn't completely change the @name to something totally different but still have it access via the old @name, etc. URL but have GM install it under the new @name.

    Honestly I'd rather just like to have a comparison of old to new and create a new indexed script... and if the toLowerCase of the url matches then possibly prompt. The basic moral here is don't change the core UserScript metadata items... will be a bit tricky to handle the logic but I think it's quantifiable since we do this for discussions already.

  7. TimidScript commented on Jul 3, 2015

    @TimidScript
    TimidScript
    on Jul 3, 2015
    Author

    Even Greasemonkey would have recognized it as a different script with the name change.

    GM keeps the same local storage name if you download from same place, no matter what changes you make to the meta. Old USO, GreasyFork, Gist and Github have same unquie id. All the sites you can rename and still have a unique id to keep track of the original.

    Anyway, I renamed the script without much thought. I forgot about OUJS unique behaviour.

  8. Martii commented on Jul 3, 2015

    @Martii
    Martii
    on Jul 3, 2015
    Member

    If you change the casing of your script name you are unable to access latest version.

    Type checks for owned re-casing test:

    • Existing script edit - change @name and any changes in entire script are omitted
    • Write script online - change @name and any changes in entire script are omitted
    • Upload script - change @name and any changes in entire script are omitted
    • Sync - pending... will have to do this at dev station since this location doesn't allow ssh connections here yet GRR
    • Changing @version and @name does affect Raw JSON data. e.g. OUJS stored metadata ... this may be the bug here
    • Script source remains original source.

    Conclusion... duplicate script made in DB with shared OUJS metadata.

    However this bug might be the result of case-insensitivity in the actual URL.

    Possibly in find* routines... not showing duplicate in script list... added security label for this part.

  9. Martii
    added
    bugYou've guessed it... this means a bug is reported.
    securityUsually relates to something critical.
    on Jul 3, 2015
  10. Martii
    changed the title [-]Script Name Casing[/-] [+]Script Name Casing Duplicates[/+] on Jul 3, 2015

  11. TimidScript commented on Jul 5, 2015

    @TimidScript
    TimidScript
    on Jul 5, 2015
    Author

    FYI: GM is case-insensitive.

  12. Martii commented on Jul 5, 2015

    @Martii
    Martii
    on Jul 5, 2015
    Member

    FYI: GM is case-insensitive.

    FYI: It shouldn't be... it should be case sensitive and is reconfirmed here. (Meta keys and values, even at the file system level, with lower case a and upper case A are different scripts)

    Mozilla/5.0 (X11; Linux x86_64; rv:36.0) Gecko/20100101 SeaMonkey/2.33.1
Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Firefox/38.0 (38.0.1 distro build)
Most recent GMs for each browser

    Invalid for that portion of this report.

    Further GM engine refs:

  13. TimidScript commented on Jul 5, 2015

    @TimidScript
    TimidScript
    on Jul 5, 2015
    Author

    Odd, retested it and you are right. First time I time I tested it, I had a script called "TEST" and "test" and one overwrote the other. Tried again and not the case. Must have made a mistake.

  14. Martii commented on Jul 6, 2015

    @Martii
    Martii
    on Jul 6, 2015
    Member

    @sizzlemctwizzle
    Misc. note(s):

    • Base issue where this was "corrected" was found being referenced in Stop using @namespace to identify scripts #130 ... with commit 5b65abd
    • Period of time reminder is when you fixed my "marti" to "Marti" username access in the URI... e.g. case insensitivity on Usernames... but the installSlugName is completely case insensitive now which includes the Scriptnames... which is a cause for this issue. (e.g. miss at Stop using @namespace to identify scripts #130 (comment) ) There may be more since then... but this is where I got a trial and error hit with seeing the missing scripts in my own investigation... which led me to the referenced issue list item and eventual commit.
    • We might not be able to change caseInsensitive search for a path separator as some script names I've seen some that do have a slash in them although I don't know for sure if they are escaped (encodeURI...) or not.
  15. Martii
    self-assigned this
    on Jul 7, 2015
  16. Martii
    added a commit that references this issue on Jul 7, 2015

    Hot fix for OpenUserJS#656

    372c885
  17. Martii
    closed this as completedin #658on Jul 7, 2015
  18. Martii
    added a commit that references this issue on Jul 7, 2015

    Merge pull request #658 from Martii/Issue-656hotFix

    07f4fd2
  19. Martii
    removed their assignment
    on Jul 7, 2015

  20. Martii commented on Jul 7, 2015

    @Martii
    Martii
    on Jul 7, 2015
    Member

    @TimidScript
    You should be able to change your casing now... it will by design spawn a new script on OUJS (if script homepage doesn't exist for you) as @sizzlemctwizzle mentioned. Let me know how it goes.

    My production Unit Tests are currently here and HERE.

  21. Martii
    added a commit that references this issue on Jul 7, 2015

    Missed STYLEGUIDE.md conformance

    02fccb1

  22. TimidScript commented on Jul 8, 2015

    @TimidScript
    TimidScript
    on Jul 8, 2015
    Author

    @Martii
    Thank you. Just tested it and it seems to work. I won't be renaming anything, as it will produce a new link for the homepage and all stats will be lost.

  23. OpenUserJS
    locked as resolved and limited conversation to collaborators on Apr 12, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    bugYou've guessed it... this means a bug is reported.securityUsually relates to something critical.

    Type

    No type

    Projects

    No projects

      Milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions