When I go to security, the group and user are not there…
After I restart Servoy Developer, then they appear. Does this happen on the client also?
I also encountered a security-risk (I think)…
When I’m not the administrator and even if I don’t have access (no read, no insert, no delete, no update) to the repository tables servoy_groups, servoy_groupelements, servoy_user_group, servoy_users and I use the method above…it still works.
Since you can’t determine in a method what the priviliges are of the user logged in at the moment (as far as I know)…i think this is quite dangerous…This means that an user with low priviliges can create an user with high priviliges (using the method above).
Am doing stuff wrong?? Or not understanding the Security part yet?
I use :
Servoy Developer
Version R2 2.0 rc6-build 265
Java version 1.4.2_02-b03 (Windows 2000)
When I go to security, the group and user are not there…
After I restart Servoy Developer, then they appear. Does this happen on the client also?
Johan says somewhere else on this forum, that this will be fixed in rc7
Since you can’t determine in a method what the priviliges are of the user logged in at the moment (as far as I know)…i think this is quite dangerous…This means that an user with low priviliges can create an user with high priviliges (using the method above).
This is the way I WANT!
This feature is build, to give customers the abbility to add users to the systems. And because YOU and I are the developer, WE have full-controll if you let this happen or not.
For example, place this method on a form, where this low-privilige-user has no access to!
Simple as that!
Quote:
Since you can’t determine in a method what the priviliges are of the user logged in at the moment (as far as I know)…i think this is quite dangerous…This means that an user with low priviliges can create an user with high priviliges (using the method above).
This is the way I WANT!
This feature is build, to give customers the abbility to add users to the systems. And because YOU and I are the developer, WE have full-controll if you let this happen or not.
For example, place this method on a form, where this low-privilige-user has no access to!
Simple as that!
Yeah you’re right…I didn’t mean to get rid of this feauture… I meant that it would benefit security if these method-steps would respect the priviliges set in the security…
But examining further I now see, how you can make it so that it would be secure anyway.