Opinions/Suggestions Please!

Hello all,

I am porting an app to a web type. The permissions use Roles. Each Role can be tied to one or more allowed pages. In each Allowed Page are permissions such as add, edit/change, view. There are many pages. Each page is launched through code in the Session, so that the session owns the page and whenever a page is created, the one calling it is destroyed.

My request for opinions is - what do you think the best way to implement the control of these permissions?

I have tossed around having each form do that during the shown event - thinking that all objects on the page are created but not shown yet; so if the page should not be shown, none of the objects on the page will be shown, only a msgbox that explains what is going on. Or if the objects are allowed to be viewed but not edited, they can be set to disabled. And on and on etc…

Another thought, which may be harder but better for the user experience, is to have the menu items disabled when the page is not allowed to be viewed.

If this all sounds convoluted, well it is! I’ve not done this in a web app and am trying not to waste resources which are a bit different from a regular desktop app.

Another such consideration is - should the code re-read the database each time, or would it be better to put all permissable pages and their permissions either in an array, a library, or a Structure? This is a mult-user system - the database is SQLite.

Thank you in advance for your opinions/suggestions!

Tim

First, make sure your webpages don’t have implicit instantiation and that you close them after displaying another, otherwise they all get loaded, and a moderately competent user can access any page with developer tools, since implicit instantiated pages are all preloaded.

What do you mean ? There is no menu bar in web apps.

Perhaps the Toolbar!?

You could use a method in the open event of each page where you specify which rights are needed for that page. If it is true, display the page, if false, open another on (default not allowed page).

You could read the userrights to an array when login is done, or ask for them when the page is requestet. The session-version is a problem, because if revoke some rights while the use is logged in, that won’t have an effect until he has logged out.
I use the database version. With having indexes set this is only a mini-select. Normally that is really no problem. When having high performance Sites huge Usertable and > some million impressions / day i use memcache for that.

Thanks for the replies!
I created a menu using WebToolbars.
The pages are not instantiated implicitly. They are instantiated only as needed, destroyed right after. This is done within methods in the session.

The default not allowed page is an excellent idea.
Thanks again guys.
Tim

On my WebApps I grey out the ToolBar items they don’t have access to. If they have view access only, I do a check on each ‘data-changing’ button to see if they have edit rights — if not, a message is displayed.

All ToolBar and button choices are written to an audit table.

I do something very similar to David Cox. I also set any controls (toolbars) to not visible by default and their visibility is turned on when their user status is verified in the database. That way, there is not a brief moment where an unauthorized user could click a button before the database returns the user’s status.

Peter, invisible data is very easy to access with any browser developer tools.

The only secure way to protect your data is to keep webpages with no implicit instance, and load them only after you have verified the user credentials.

In other words, use a welcome page with nothing else than the login.

[quote=314799:@Michel Bujardet]Peter, invisible data is very easy to access with any browser developer tools.

The only secure way to protect your data is to keep webpages with no implicit instance, and load them only after you have verified the user credentials.

In other words, use a welcome page with nothing else than the login.[/quote]

I have an admin panel that uses implicit instances for each page, I can’t seem to find any sort of data for pages that I haven’t called the “Show” method on. That being said, I also have a permissions system on every user action from showing data to modifying data, the worst they could do would be to mess with the CSS or call events for buttons that are protected app side anyways.

It is way easier to switch off implicit than having to do all sorts of convolutions to prevent access.

Smart, I also have per-control permissions, so I already had the system in place to restrict access.

[quote=314799:@Michel Bujardet]Peter, invisible data is very easy to access with any browser developer tools.
[/quote]
Is this true for itemName.Enabled = False as well? I usually set my objects to be disabled by default (rather than invisible). I would not like it if a developer could Enable any object they wanted!

With developer tools, one has access to ALL the content of the DOM. Meaning that yes, it is quite possible to change the status of a control.

Someone with a good knowledge can also fetch the Xojo framework file and start reverse engineering many things.

The only way to prevent hacking is for controls not to exist in the DOM. For that, only not loading the WebPage will protect it’s content.

Good, my login page is entirely separate from the other windows and I don’t load any other WebPages until they have a correct login. I can trust my logged-in users since it’s their data! Thank you.

Make sure implicit instance is not true for your webpages. Otherwise they are preloaded and in fact accessible.

There is a login that obtains the credentials, stores them in a Session variable, and then loads a page. If the variable is Option A, then is displays one toolbar, if it is Option B, it displays a different toolbar. Do you think that would still be easily reversible?

If you are simply making a toolbar invisible, then it is easy to change visibility. A more secure way would be to place each toolbar in a WebContainer, and instantiate in code only the one needed. So the only one existing in the browser would be the authorized one.

Ahh, I see. Very good. Thanks!