About two days ago we found a bug with the registration system on lemmy. Because of this we have updated our registration process a few times, and cannot deny any applications as the person registering does not receive any message and cannot re-apply.

We currently have several hundred people that we are waiting to deny, and some unknown amount of people that we denied prior to finding this issue which we would really like to contact and give them a chance to register as they didn’t write enough in their registration for us to really evaluate if they were a good fit for this instance.

If you’re a developer please take a look at this github issue and please work your magic to help fix this problem.

As an aside, we also have a list we’ve been working on for enhancements that would make moderating and administering this instance a lot easier, and enhancements we think users would enjoy in terms of UI and UX. We’d love to share these as well as facilitate a discussion to surface more ideas (and we plan to in the future), but right now we need to focus on the most pressing issue to us running this website, whether people can create an account here and participate.

  • Rentlar@beehaw.org
    link
    fedilink
    English
    arrow-up
    14
    ·
    edit-2
    2 years ago

    A “quick fix” might be to test for a user unapproved status on login and provide it as a status (e.g. 404:application_denied). Then the behaviour can be either release all created but unapproved accounts after 24hrs elapse or perma-“ban” until approved like it is now depending on server preferences.

    “Quick fix” as in it’s seems quick but will take me a while to implement if I were to try and I won’t have time for a few days to get serious and become familiar with the code.

      • chinpokomon@beehaw.org
        link
        fedilink
        English
        arrow-up
        10
        ·
        2 years ago

        Servers may also send [a 404] response instead of 403 Forbidden to hide the existence of a resource from an unauthorized client.

        In this case, I agree that 403 is the better response, but for some resources, in the name of security and privacy, 404 might be more appropriate depending on the request.

        • ultraHQ@beehaw.org
          link
          fedilink
          English
          arrow-up
          8
          ·
          edit-2
          2 years ago

          Yeah at work we mask all responses to the client in production to x00, but in the scenereo the original commenter laid out exposing the 403 would be best.

          Adding a modal client side would prob be best here.