User Registration scenario to include : invitation (protection)

Feature Request

To prevent anybody to open identity onto Sphinx, please can you consider to integrate invitation support ?

  1. sending email + invitation code > email invitation with preregistration inside sphinx
    Exposed by an Endpoint in Sphinx API to fire such invitation from linked applications backoffice.
  2. authorization to register using email + invitation code to continue
  3. blocking direct registration

I wish I could give this 10 votes!

Even knowing that you can disable user registration from the UI and add the users manually yourself?

Just after I posted that I realised that it would be simple enough to intecept any direct calls in the server application. So I've removed my vote :slight_smile:

Hm, can you elaborate? What are those call interceptions?

If Sphinx is just an extended XData Server, can't the calls be intercepted on the server events? I must admit I haven't looked at it, will try to this weekend.

If not, then the request still stands as you'd really need to enforce these rules at the server level, not just the on the UI.

Yes, you can intercept anything, using middleware, for example.

But, for some reason I the ability to disable the "new user registration" UI was already implemented in Sphinx, but it's not. So I think this is a different feature request.

I created that one here:

Thus, one thing is the ability to disable user self-registration (the above feature request).

Another thing is the ability to create a new user from code and ask for invitation (this feature request).

Although if you require e-mail confirmation, even if you create a new user from code, user will have to confirm his e-mail to create the account, thus I'm not sure if this feature request here is still meaningful?

2 Likes

Disabling in the UI only hides the link. Anyone that can hit F12 in their browser to view the source can see the link that is hidden can copy it or follow it to continue the process and register. Need ability to remove it completely for some of us. Hiding it is a temp solution.

Correct, that's why I created the mentioned feature request, which is a request to implement such removal.