1 2 3 Previous Next 36 Replies Latest reply on May 14, 2014 5:40 AM by raycon

    User Account handling


      Hi All,


      As a newbie, I'm swamped with the amount of differing opinion on handling solutions with large numbers of user accounts, and the security of those solutions. This issue has become even worse with the release of WebDirect, because whilst that's developing into a really useful tool for me, I have not yet found a pretty way of handling user accounts.


      I've spent the last three days testing a solution based on an external (iOS in this case) file which is authorised by a hosted file. The idea uses an open login to the iOS file and a "re-login" on the hosted file, and by golly I think I can make it work. But then I read opinions stating that I've reduced the security of my solution by taking the locks off the car door and relying on the ignition key.


      I have a hosted file and an iOS app (and am developing a WebDirect app) which accesses the files on the host. Obviously I am avoiding both sync problems (I must for this client) and having to update the iOS device every time a user or permission changes on the host.


      Is there a resource somewhere which explains in simple terms the best practice for security in this situation? Google can't seem to find one for me.


      Or, more correctly, I can't find a resource, so can someone point me at the best one?





        • 1. Re: User Account handling

          "But then I read opinions stating that I've reduced the security of my solution by taking the locks off the car door and relying on the ignition key."


          I would turn it around. Do the people making this statement have any basis for it, or are they just giving you their opinions?

          • 2. Re: User Account handling

            I was the one making the car analogy, and yes; there is a basis for it.  It's kinda obvious too: once you let a user in, they are in and have more attack vectors than someone that is still trying to get in.


            Whether it is something you need to worry about depends on the value of the intellectual property of the solution, the value of the data, etc.

            • 3. Re: User Account handling

              How does that apply to the practice of an opener file with minimal privs, followed by a login?

              • 4. Re: User Account handling

                The reason I ask is, if I understand the question correctly, the application in question uses a local file on iOS to access a hosted file on Server. To configure such a local file correctly, the auto-login should have only very minimal accesses - just enough to get logged in and request credentials. The local file should be almost a "dummy" file with very little in it.


                Or am I missing something?

                • 5. Re: User Account handling



                  What you are describing though is a combination of two things:

                  - the opener file

                  - and auto-login


                  Opener files in their simple form do not auto-enter the user in the target solution; they are just shortcuts to the hosted files and don't attempt to log the user in: the user will be prompted for credentials before the target solution gets opened.


                  In your scenario, you are combining the "shortcut" with "auto-login".  It's the auto-login that puts the user inside the file without a challenge.  The scripted challenge comes after they are already in.

                  • 6. Re: User Account handling

                    Mike_Mitchell wrote:


                    To configure such a local file correctly, the auto-login [...]


                    This part is not correct. There do not need to be any credentials in the local file that also exist in the target solution.  The local file can auto-login with the default admin account for all we care, because it just serves to make the initial connection to the hosted file.  When FM Go attempts to open the hosted file the user will be asked for credentials.  The target solution does not need to also auto-login for this mechanism to work.

                    • 7. Re: User Account handling

                      Not missing anything Mike, that's what it is.  The iOS file has layouts and scripts but no data (except the "global" master).  Login to that is automatic.  A trigger script is run which captures user/pass and then calls a re-login on the hosted file.  If an error (212) is generated on the host, the iOS client either closes or gives you another go, depending on how you script it.


                      Obviously the auto login on the client has minimal privileges.

                      • 8. Re: User Account handling

                        Wim's concern comes with whether or not the auto-login account in the local file also exists in the hosted solution. He is correct; this is a definite no-no. You can have an auto-login if you like (to avoid users having to log in twice); just make sure you don't use an auto-login to an account that actually exists in the database.


                        This also applies, as Wim noted, to opener files.


                        Now that I understand what's going on ...  

                        • 9. Re: User Account handling

                          Hmm, just to be clear, the initial login to the client is an account with a username that does not appear on the host, not even with minimal privileges, because that gets them into the car?  That's what I have atm.

                          • 10. Re: User Account handling

                            Let's back up a second here. It was my suggestion originally, and I don't see what's wrong with it.


                            The original question is complicated a little by the separation model, but the issue Mike and Wim seem to having is with the "Log in using..." in the File Options.


                            My suggestion is to have an account in the hosted file set to log in automatically. Let's call it username "login". With no password. Yep, sounds scary. But that account's privilege set would be permitted to access no layouts, no value lists, no records, and only a single script: Re-login. That "Relogin" script would be set to run On First Window Open and would have the Re-login script step and some error handling for bad attempts.


                            What is the actual security hole here?


                            *Please note, the actual solution I suggested was to have this separated, and have the re-login on the client, capture the credentials in Custom Dialog globals and pass those to the host for login. Rethinking it, I'm not sure if that's even possible without having the host credentials in the client file or triggering the host's native login.


                            Message was edited by: DavidJondreau

                            • 11. Re: User Account handling

                              Correct. Use their “real” account to log into the host. The local database doesn’t have to demand a login; it can use a default account with minimal privileges that doesn’t exist on the host. But you don’t want someone accessing the hosted database without presenting credentials.

                              • 12. Re: User Account handling

                                But you have to open the host file to be able to use the re-login script, otherwise you're back at the beginning, losing control of the login process and leaving it to FM which means being re-presented with logins?  Presently my clients don't seem to notice whether they're being preented with a dialogue for teh Client or teh host, and frankly I don't think they care.  But what happens after a disconnect is that they're presented with a login to the client and when they (blindly) use their host credentials and are refused, they call me.  I've got into the habit of one-word responses, like"re-boot".


                                What option is there but to open the host file with another dummy login with privieges set to only allow access to the one "re-login" script?



                                • 13. Re: User Account handling

                                  Okay, now I'm confused. What exactly are we trying to accomplish? Such a scheme just mimics logging into the file, doesn't it?

                                  • 14. Re: User Account handling

                                    You have to trigger the host's native login, I've tried it.

                                    1 2 3 Previous Next