Client Id and Client Secret during registration from Client App?

Authentication & Security
1

Hi,

Is there a way to implement a Client Id and Client Secret security for the Rest Api calls?

My concern is that if someone finds out the DSP url, they can just create a script to do some sort of registration spamming.

Like for example, the endpoint for registering a user is $YOUR_DSP_URL/rest/user/register and anyone who knows about dreamfactory knows the endpoint, http method and payload format.

Appreciate your feedback on this.

Regards,
Allen

2

I’m assuming your use case requires that Open Registration remain enabled?

Otherwise you can just keep open registration disabled and use an email template and the built-in confirmation code generation to send user invitations.

3

Hi,

Not sure if disabling the Open Registration is applicable to my case. The application I’m building is open to the public. The concept of creating users is similar to those of Google Plus, Facebook where users can simply sign up to use the service.

Are there any other ways to secure the Open Registration?

Regards,
Allen

4

That’s exactly why I asked.

In your case, then, I would recommend writing a user registration page into your app that calls /rest/system/user to create a DreamFactory user like the example from the documentation page I linked above:

POST https://api.mydomain.com/rest/system/user?send_invite=true

POSTed data:

{
  "record": [
    {
      "email": "user@domain.com",
      "first_name": "User",
      "last_name": "Name",
      "display_name": "User Name",
      "phone": "6785555555",
      "is_active": false,
      "is_sys_admin": false
    }
  ]
}

With send_invite=true in the URI, no initial password value provided, and "is_active": false in the POSTed JSON, the user will be sent an invitation email according to the email service and templates you have set up in Config for this purpose:

From: App Name <api@mydomain.com>
Date: Wed, 01 Jul 2015 12:53:19 -0400
Subject: Invitation to App Name
To: user@domain.com

Hi User,
You have been invited to App Name. Go to the following url, enter the code below, and set your password to confirm your account.

https://api.mydomain.com/dist/#/user-invite

Confirmation Code: d820e0ee2b5f33c779f4b3c9da24575f

Thanks,

App Name

If this added step of user self-confirmation is insufficient for your security needs, then I suppose your best bet would be to write a server-side script to intercept the registration POST and verify a shared secret before allowing the POST to continue by calling platform.api.post("system/user",*{payload here}*); from within the script.

1 Like
5

Hi,

Thanks again for the quick response.

I tried your suggestion and used the following as suggested.

POST https://MY_DSP_URL/rest/system/user?send_invite=true

Unfortunately I got a Response Status of 401 Unauthorized with the following body.

`{
error: [1]
0:  {
context: null
message: "There is no valid session for the current request."
code: 401
}-
-
}`.

Not sure if I’m doing something wrong here. But I managed to get it to work when I added the X-DreamFactory-Session-Token on the header.

Please advice.

Thanks,
Allen

6

I just tested again and it worked fine for me. Since obviously users who are registering themselves won’t have a valid session_id, are you certain you’ve set up Guest Access with a role that may POST to /rest/system/user?

Here was my call:

POST /rest/system/user?send_invite=true

JSON

{
  "email": "user@example.com"
}

I received my invitation email almost immediately (in my test I POSTed a real email address).

If I disable Guest Access, I do receive this:

401 Unauthorized "There is no valid session for the current request."

And if I re-enable Guest Access but with a role that’s not configured properly, I receive this:

403 Forbidden "Access to application 'appname' is not provisioned for this user's role."
1 Like
7

Hi,

My apologies. I had the Guest User disabled. I got it working after doing the following setups:

  • Create a Role “guests”.
  • Enable Guest User in Config and assign role “guests”.

So basically users can register but remains inactive until confirmed. This is great! I can probably create some sort of scheduled job to purge inactive users for a certain time.

Really appreciate your help and support.

Keep up the good work.

Regards,
Allen

1 Like