Security: does building your own security leave a hole?

Hello,

After consideration, we are planning to build our own security and expect not to use Servoy’s built-in security users/groups. One question this brings up for us is…

If we do not enable servoy’s login dialog but control client access via form entry and methods, how do we prevent someone with Developer and our solution url from opening the solution and having free reign?

Apologies if the answer to this is right under my nose. I’ve searched the forum and the docs and have not gotten clear about it.

Your solution source can be protected by adding a password to it via the repository.

Accessing your solution via a client or developer has nothing to do with the behavior of the solution. This means that, when you have a login screen, you would have to go through that screen to log in. No exceptions here…

But why do you build you own security I wonder?

Ah, so if our opening method throws a username/pw dialog (and has appropriate controls so user can’t cancel out of dialog). Then there is NO way a Developer user could get past the dialog w/o username/pw access?

Are there ANY conditions under which the opening method won’t run (I know that occurs at times in FileMaker)? Because that would be the key to our security.

I remember maybe seeing a post about opening methods not running when a module is opened. But if that is true, it shouldn’t affect us. The opening method in question is for an actual solution which will function as the entry point to access the other modules.

So then, why build our own security…the company has a dozen plus departments. But they aren’t just distinct departments in all cases, often people have multiple roles and they cross “departments” on a regular basis throughout the day.

Within a department, there is essentially no controls needed on security (once you are in, you are in). The minimal that there is we might use Servoy’s built-in security (ie Worker group and Manager group).

To keep security, development, and the GUI more clear and distinct, we decided to build a solution/module for each department.

Our security databases:
groups (ie departments)
users
solutions
solution-groups
user-groups
will allow us to see who has access to what.

So our control point is focused on whether or not you can gain access to a solution. And that meets the requirements of 99% of our security needs.

Feedback welcome.

Ok, the picture is becoming clearer.

Protecting the solution via the Repository will prevent any Designer or Editor access without a password.

An additional layer of protection is available by triggering an onOpen method to showFormInDialog. We will make that a login form which requires username/password entry. Users who open the solution with client or developer will be forced to use the button provided on the login form. The button will check their username/password entry against our custom built security tables. An onClose method will provide controls in case they click the closebox at the dialog. So, no user should be able to get beyond our custom login dialog without a valid username/password.

Also realized that we cannot use a combination of our own security and servoy’s built-in security unless we force the user to login using servoy’s interface.