in general, account data should go into the account object in the Administration module, or in an object in one of your custom App modules that inherits from account . Note that account itself inherits from system.user
When you refer to a public mobile app, what do you envision? In essence, if you want user to have access to specific user-account related data in the App you will be storing their "login credentials" etc, in the App and you will be consuming user-license-slots. If you mean to set up an App that allows general access, there would be no need to register accounts? This consideration will influence a lot of things.....
There are people better able to explain the AppCloud users, but let me try to give you an indication. If you run a Mendix license with multiple slots, there are probably people in your organisation that would have access to several of the running applications. If you define them as AppCloud user, they will consume user-license-slots differently.
For standardized stuff, check the AppStore, a lot of the stuff you are looking for s already there, but look for modules, not widgets! or try one of the Mendix Samples.
I can sketch you one of the solutions we have used.
1) make sure your security allow for GUEST access to the App 2) create a "outward looking" landing page. make sure the guest-role has security right on that page 3) This page should be linked as the starting page for GUEST 4a) on the page you will need to provide a "normal login widget" (as ALL users start as guest and will end up there, and from that place will enter the App once registered 4b) on the page you will also need to provide an ACTION/MF button which allow a person to register 5) rig a MF behind that button which allow for the creation of, what for the ease of communication I will call Registree. This Object needs to be defined in a Domain-model and should consist of the basic/primary data for the account (NOTE: do NOT inherit this one from system.user or account .
without knowledge of the checks and balances you want on a Registree I will skip that part, and assume that under the right conditions the Registree will become a User.
6) create a MF that moves the relevant stuff into Account (or an inherent object) and kill the Registree-info (unless you need that for other purposes.
Again, there are several options after this, the most logical one is to bounce the Registree back to the portal and let him use the now functioning loging-form to enter the App. depending on requirements you could force him to validate Email and allow 1st time entrance from there, but without more functional/background there are to many variables from this point onward.
Thanks Lex! I'm still puzzled, though. I can find documentation of settings & technical How-To's, but no descriptive text about the concepts of Mendix user management.
It seems to me that things assume to have a pool of users predefined by an Administrator or through integration with LDAP or something. What I'm looking for is having users to register a new account themselves. The users of my app are not part of my organisation. That's what I mean with "public".
I did find an OAuth module that looks interesting (though linking to existing credentials would actually be more of a nice to have to add in a later stage), but it's not available for Mendix 6. Its documentation mentions "user provisioning" ("If you do not implement user provisioning then the users have to be known in the app by integration to an Active Directory or an Identity Management solution ") - is that a common concept in Mendix; where could I find more info?
I guess the simplest form of my question is: How can I let new users sign up for my service/app?
First you need to activate anonymous users. This way people who are not a member yet can have their own landing page. In the navigation settings you can define for each user role a different mircroflow or landing page as a starting point. On this page you should also make a button to redirect the regular users to the login.html so that these users can enter their credentials. On the landing page you can create the sign up routine so the user transfers from the anonymous user role to a normal user role. If you have more questions edit your original question with the edit button. Try never to answer your own question.