Hi folks – I really did try to find this info in the documentation but don’t see any reference to a way in which I can protect an application from being modified by someone else. Clearly when something is installed at a client’s site, the usual scenario will be that they know the username/password to their own server, so what can I do to prevent someone from simply creating a connection and using Developer to modify what’s been installed?
Thanks. I hope this was a dumb question and that there’s an easy way to do this that I’m not seeing!
You can disable a lot of the functions with the form events. But to have full control over the menubar you can use IT2Be’s menu plugin. http://www.it2be.com
SV-Kelvin:
especailly the “Select → Delete All” button , whuch the user can delete
all teh records in the database.
Set the form event (see form properties) onDeleteAllRecordsCmd to -none-.
Can also control a lot of actions from within Servoy: check the Form Propteries in Layout mode ie onDeleteAllRecordsCmd you can change to ‘none’, ‘default’ or assign one of your own Methods.
Thanks to all for the answers, great community support, yes!
I need to ask you to bear with me here, maybe I’m missing something. The section in the documentation on Security only discusses establishing control over form elements, read/insert/update/delete privs, and logging.
What I was concerned with was controlling access to “my intellectual property”. In other words, I do not want any users to have access to view methods, calculation formulae, or data provider/relationship info. Are you guys saying that if I create a group called Administrator, that is the only group that can do these things?
The docs only discuss field and record level security in the “securing your solution” section of the Security chapter. There is no documentation I can find relevant to actually protecting the programming of your solution. Did I miss something?
If I understand your question correctly then I think the answer is as follows:
If you are wondering whether a ‘regular’ client has access to the things that you mention:
What I was concerned with was controlling access to “my intellectual property”. In other words, I do not want any users to have access to view methods, calculation formulae, or data provider/relationship info. Are you guys saying that if I create a group called Administrator, that is the only group that can do these things?
the answer there is no client (even a client using an administrator password) can see those things when logged in as a client. Those things can only be seen in Developer Mode with an administrator password.
2) If you are talking about the solution itself then you can export the solution with a password so only someone with that password can access the solution.
3) If you are talking about someone accessing your solution in Developer Mode, then only people with Administrator priviledges can access those items you refer to as your “intellectual property”.
My two cents worth…
Our work is protected. But bare in mind somebody that wants to crack your stuff is always able to do so with whatever environment you created and whatever security you have built. Everything can be reverse engineered to it’s original code. Even binaries…
Thank you, John, for the clear explanation. I really wonder how much time people spend testing to figure out these behaviors, because I could not find any information about securing access to design elements in the Security chapter. Only access to forms and data is discussed there.
Anyway, first of all to clarify, my concern is what John wrote as #3,
If you are talking about someone accessing your solution in Developer Mode, then only people with Administrator priviledges can access those items you refer to as your “intellectual property”.
But then nobody at the client site can add new users? My clients would need to call me to request password changes?
I’m only seeking some way of preventing my customer from making design changes or from simply sharing the application with their colleagues, but they must be able to add users. This is a university press. When I went on the original visit to their office my contact showed me the application they are currently using, and the splash screen clearly showed the license was registered to a different university! This woman unapologetically explained that university presses don’t have a lot of money and so they very frequently share their software with other presses.
IT2B’s point is wel taken about anything being crackable. This is more about “keeping honest people honest”.
So the question becomes, if nobody at the client site has administrative access, is there some other way to enable them to add and remove users, and how would they do this without a copy of Developer? Could script the process and grab usernames & passwords from a global field, and if this method is run on a client that is logged in with not-admin privileges, would it work?
Sorry, again, if this is covered clearly somewhere in the docs.
Your solution is password protected when you add a password to protect it. If so one can have whatever rights but he still needs to know the password and have the developer running…
I really wonder how much time people spend testing to figure out these behaviors, because I could not find any information about securing access to design elements in the Security chapter. Only access to forms and data is discussed there.
I agree it is a bit overwhelming at times as to where things are covered in the documentation. My own feeling is that the documentation is rather good, actually very good, but the problem is with those buggers who keep developing Servoy: they keep making it better and adding more functionality so we have more places to look! But security is handled in two places in depth, the place you mentioned but also in ‘Methods’. It is within the ‘security’ part of the Methods section that you can figure out how to give your clients the ability to add or drop users, change passwords, add or drop users to different groups, etc. WITHOUT their having access to the actual method editor, forms, tables, etc. (in other words without their actually accessing the inner workings of your solution). It would be easy to skip over I’m sure but mention of this is made in the main ‘Security’ section that you have looked at (see below).
NOTE: Security can also be accessed as part of a Servoy method. For a list of security functions, refer to Methods: Security in the Servoy Developer Edition Reference Guide.
```But definitely don't feel bad about missing this and asking for help. Lord knows I have asked for things many a time that have been much more obvious than this. It just takes a while to get 'comfortable' is how I would describe it. Where everything just starts to make sense. One thing I would recommend that helped me is I would just spend a few hours reading the documentation like you would a novel. Don't try to 'learn' everything, or start experimenting with things at your computer but just casually read the main books, the two 'Servoy Developer Editions volumes 1 and 2' and, if you come from a FM background, the 'Advanced Programming Guide for FM developers'. For me I think that is the fastest way to get the lay of the land, so to speak, rather than diving right in. It also gives you a better understanding of where to start looking when you are lost and makes it easier to search and ask questions on the Forum. At least that's what I found. I guess that's three cents worth now...