User Management without email password

I use DSP to access Remote SQL DB and for other email services etc.

I mostly use it along with angularJS front end. However, my apps don’t have emails etc for the users. Sometimes it could be mobile number as well.

Can you please let me know how can I manage my sessions? As of now I am using guest roles, and giving them access, but in that case everyone gets admin access by default.

Please guide me as to what is the best way to do the same.

Please note I have my user specific details etc stored on my Remote DB.
Do I need to write my own Oauth system, if I want my authentication, but yet want to use your session management. So, the best of both the worlds?

1 Like

Hey Praveen, please hold tight for 2.0. It will be in beta very soon, I promise. We’re working around the clock to ship the beta before the end of the month. This will address all of the needs you mention, including clean OAuth integration, JSON web tokens, email not required for login, permanent sessions with client token refresh, etc. etc.

You will want to upgrade to 2.0. We’ll have migration scripts that will port your existing 1.9.x apps to 2.0. Hopefully you are on 1.9. More info coming soon, stay tuned!

Very good, I have the same problem, now I’m developing my platform in version 1.9, I’m looking forward to be able to migrate to 2.0

How to do this in DF2? beta is out for a while but no documentation yet :frowning:
I want to authenticate my users with custom fields other than email/password. I have added those fields in db but still login request returns email is required.

I wouldn’t call it no documentation, but I don’t think anything that covers this specifically is up on the 2.0 wiki yet. Stay tuned!

Hi All,

As per my understanding in 2.0 you folks have added many Oauth platforms now like FB, Google etc.
However, what if my users are using mobile number or some other custom method, and also are using a remote DB which is connected using DSP.

This is the only issue which worries me for using DSP, as I dont think there is any way to safeguard the REST APIs. Opening up everything to a guest user seems to be the only way, but that is compromising with security.

Please help with the solution. Or if there is any hack etc.
I was waiting for 2.0 hoping this would be addressed in it but it seems you folks have only added FB etc now, and custom Oauth is not yet present.

This is a sample script that will do the custom login and return JWT on success. I received this script from one of the DF engineers. Let me know if this works.

if ('POST' === strtoupper(Request::method())) {
    $credentials = [
        "email"     => Request::input('email'),
        "password"  => Request::input('password'),
        "is_active" => Request::input('is_active')

    if (\DreamFactory\Core\Utility\Session::authenticate($credentials, Request::input('remember_me'))) {
        return \DreamFactory\Core\Utility\Session::getPublicInfo();
    } else {
        return ["success" => false];
} else {
    return ["success" => false];

In this script I am using email, password, and is_active field combination for authentication. You can modify this to use whatever fields you need. You just need to put that in the $credentials array from Request object. So, go ahead and create a PHP custom scripting service with this script under the services tab. Now, by default this service is not accessible without logging in the system. So, you need to create a role that only needs to allow POST on this custom scripting service. Then you will need to create an app and assign this role to the app. Now you can use this app’s API key to call this custom script and login! I have tried this and it works. On success it will return same response as user/session. But if user credentials don’t match, it won’t return 401 (unauthorized). Instead the script will return a 200 with {‘success’:false} or whatever you configure it to return in the script; but it will return code 200.

We had a similar problem, requiring MSISDNs instead of emails. We used an adapted form of the standard DreamFactory 1.9.x user registration. The basic characteristics of the solution for registration were these (from memory ) :

  • the app would make a call through DF to a remote service to begin a registration
  • the remote service would turn the MSISDN into an email-style address, e.g.
  • the remote service would use an admin role to register the user via REST call on the DF instance
  • DF would be configured to use a ‘sendmail-like’ script to send the registration confirmation email, the script was just a python MIME email parser that unpacked the message, and re-sent it to an SMS service
  • had to track down the script that produced the confirmation code to reduce the number of digits to something more user friendly (android app could read the received sms but IOS couldn’t)