I have multiple apps running on single dreamfactory instance.
I have a situation where a single user having email e.g. abc@abc.com have registered using one app and now want to register for another app using same email but want to have different password for that one.
How should I handle this scenario?
What I am thinking is that this could achieved in one way by adding user’s email as abc+app_name@abc.com which probably make it unique to each app.
But I would like to use the standard approach others dreamfactory developers are using to handle such scenario.
@mrvipinkashyap Having a different password per app is part of the problem. Each user can be assigned a different role per app but the user is a single entity. If you didn’t have the password requirement, an admin could assign a role for that user to the new app. This still isn’t ideal, as this would require admin interaction instead of self registration. This sounds like a good feature request for registration that I will bring up with the team (that is self-registration per app for already registered users).
It may be possible to use a preprocess script on the registration to override the app and role assignment possibly, though this is obviously not common. In other words, there is not a standard approach to this scenario.
I think the issue is not quite the one you are addressing.
So a users registers to an app called MyApp1 they now register to another mobile app using the same DF instance called MyApp2. However they get registration failed because they are already in the users table. This would be strange behaviour to the user they might not even know that MyApp1 and MyApp2 are developed by the same company.
I guess the crux is why are users not linked directly to an app rather than instance?
The only work around I can think of is like vipin suggests to make the emails unique by adding the app name to them. That is a rather hacky thing to do with such core DF behaviour as user registration.
@Matt_2012 I was primarily trying to articulate that our intention was that a single user could have access to different apps on the same instance, but that it happened by user-to-app role assignment (i.e. a single user object). The registration part is definitely lacking and is being discussed currently to allow this type of scenario.
I see your point about the end user NOT knowing that the two apps are developed by the same company, but our initial view, and I think a more valid use case, was that a user could access multiple apps/products made by the same company without having to duplicate user info/authentication.
Yes I think the design makes sense for a large company making lots of in-house apps. Where users belong to the company primarily so 1 DF instance 1 user account. But if you are a startup mobile app company tieing user registration to the api framework makes no sense. Maybe a fix would be to have a flag that says users tied to an app. In which case my workaround is built in i.e. appname is appended to email appName_email@address that way the system treats them as unique but we can still use forget email system apis because they could handle unappending the prefix. That might be the only way to work with the grain of the current set up? @leehicks
This is exactly the issue I’m facing. Apart from the problem at registration, I find that my users from MyApp1 can also login to MyApp2, where both the apps have nothing in common. DF Support team suggested for writing script in login pre-process but there should be standard solution for this common scenario. @leehicks Are there any thoughts being given to this problem? Sharing users across multiple apps should be a feature and not a rule in Dreamfactory.