Skip to content

Cleanup usernames created with invalid characters in community providers #824

Closed

Description

@justinwb

We'll need to clean up usernames that were created with invalid characters (e.g. periods, etc.) on inrupt.net and solid.community after we push the validation fix in #818.

I would propose that we do a quick search, pull the associated e-mail, and shoot them an e-mail letting them know that we need to change their username, or render it inactive unless we hear back from them with an update to it.

Activity

  1. mintunitish commented on Oct 18, 2018

    @mintunitish
    Contributor

    Is this done? If not can I grab this issue?

  2. kjetilk commented on Oct 18, 2018

    @kjetilk
    Member

    @mintunitish Thanks for volunteering, but I think this is something we have to do on the backend, so we would need to do it internally.

  3. megoth commented on Oct 31, 2018

    @megoth
    Contributor

    I realize now that I misread this issue a bit: I was thinking it should include blacklisted usernames as well.

    With that said, should this issue include blacklisted usernames as well? (I think it should.)

    And in any case; what process do we want to set up for this?

    1. Should it be a script that simply removes invalid usernames?
    2. Should it communicate to the owner that it is problematic, and given a set time to change it?
      2a) What if the owner hasn't given an email; should we add a bit of markup in the index as a notification?
  4. self-assigned this
    on Oct 31, 2018
  5. melvincarvalho commented on Oct 31, 2018

    @melvincarvalho
    Contributor

    @megoth there's no real way to fix it. What I think should be communicated is that our systems had an error during account creation. Certainly not tho only approach, but I think a reasonable one. Happy for other ideas.

  6. kjetilk commented on Oct 31, 2018

    @kjetilk
    Member

    Yeah, I think we need to give a notice in advance and apologize for an error during account creation....

    The blacklist should be involved, as well as the sanitization that we now have in place. We should send an email out first, and then allow a couple of weeks before we remove. So, this is basically the work of a couple of one-off scripts.

  7. megoth commented on Nov 5, 2018

    @megoth
    Contributor

    Ok, so this is the process that I'm considering.

    1. Adding command blacklist to bin/solid: by default it would give you a list of usernames that are in violation of the current blacklist
    2. Adding option --notify: this will add a note to the top of a user's index.html and send an email, if possible, that their username is in violation of our blacklist and will be deleted within two weeks unless they send an email to the POD provider requesting a new WebID
    3. Adding option --delete: this will delete the usernames

    Does this look ok? I could automate step 3, but think it's better with a manual step for now

  8. Ryuno-Ki commented on Nov 5, 2018

    @Ryuno-Ki

    What about renaming those accounts? Say replacing periods with dashes?
    Then you would „just” have to inform them that the name changed.
    (I had not looked into implementation details here).

    Regarding the blacklist … pay attention to have a robust RegEx (there were some DDoS attacks against RegExps the other day … at least SNYK.io sent out some warnings - can dig up details if needed).

    https://github.com/minimaxir/big-list-of-naughty-strings gives a list of possible candidates to throw against your algorithm.

  9. megoth commented on Nov 5, 2018

    @megoth
    Contributor

    @Ryuno-Ki that is another way of doing it, sure; I'm good with either way.

    We've already implemented a BlacklistService btw (#893) that makes use of https://github.com/marteinn/The-Big-Username-Blacklist. The service is not making use of any RegEx, it's simply checking a giving word (in our case username) against a list of blacklisted words.

  10. megoth commented on Nov 5, 2018

    @megoth
    Contributor

    Sorry, I seem to forget that this issue is not only about blacklisted usernames O_O

    I'll rename the command so that it doesn't only pertain to blacklisted usernames.

    Does the command invalidusernames sound like a catch-em-all?

  11. Ryuno-Ki commented on Nov 5, 2018

    @Ryuno-Ki

    Left some comments.
    While I am looking at how usernames are computed …

    Falsehoods Programmers Believe About Names is worth a read also.

    Looking at https://github.com/solid/node-solid-server/blob/9b627e47ee191ea7b2a8f1710eb6a8a952e5557e/lib/requests/create-account-request.js#L202 - it looks like you would ban every non-alphanumeric username.

    I am wondering what an international audience would do here.
    Maybe you want to follow established frameworks like django's slugify which uses unicodedata to normalise strings.
    There are pendants in node like unorm or normalize-strings-npm5 to achieve that (I'd tend to unorm, since the latter uses a RegEx …).

  12. megoth commented on Nov 5, 2018

    @megoth
    Contributor

    It is important to note that usernames are exposed in the URI of a users' POD, so we need strict rules on which usernames we accept. But in that sense we could accept all usernames that are valid subdomains, and we are limiting that today.

    I propose we create a separate issue to allow more characters in the usernames (I'm starting to sound like a broken record when it comes to suggesting to create new issues =P )

    @Ryuno-Ki Maybe you want to create an issue for it? Or if you want to discuss it with the community first, I suggest creating a thread on https://forum.solidproject.org/

  13. megoth commented on Nov 8, 2018

    @megoth
    Contributor

    I'm well on my way to completing the step where we inform the users of their invalid username. But I need to configure which email-address we should give users that want to move their username. I'm wondering where I should code this, and can think of a couple of options:

    1. As part of the init-process, so that it resides in config.json, or
    2. As value to the --notify option in the script

    Both can be done of course, but I'm leaning toward option 1, as I think it's smart to have this support-email address for the POD provider in general.

    I'll start with option 1, but am open to suggestion (hence this comment).

  14. justinwb commented on Nov 9, 2018

    @justinwb
    ContributorAuthor

    @megoth Seems that both could be valuable. By default it pulls the value from config.json, but if the --notify flag is passed, then let that take precedence.

  15. michielbdejong commented on Jun 20, 2019

    @michielbdejong
    Member

    @kjetilk can this be closed?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

Labels

No labels
No labels

Type

No type

Projects

No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions