I am trying to work my way thru managingb custom permissions etc.
The senario is that on a Master Menu two Menu elements - Search and LogOn/LogOut - with its menu items - are set with Permissions of "none", all other menus, submenus have a permission level of 10. and thus the the Logon part of the menu is accessable when the page is launched.
I have custom logon subroutine that checks usernae etc and retrieves permissions etc from a file as per published examples.
1. I had tried to modify the parent menu based on logOn userName - and this seems to work BUT with or without parentmenu modification, permissions donr weem to translate thru - exposing and allowing user access to other parts of menu. I havn't yet added the O4WCUSTOMPERMISSIONS to the Configuration - is this the issue?
2. When I have the login, or whatever break to debugger, and inspect @ADMIN this is set at 2 rather than what I expected of a ordinary User - is this simply an artifact of running the environment in debug mode - or is all O4W at @ADMIN=2 level?
Why do I care? Well, I have a security MFS on a table with the code set to skip if @Admin=2 (to facilitate Admin debugging).
3. Standard OI Commons that are initiated in an O4W session, are the values shared with other log-on sessions or are they local? - just want to be 100% sure.
4. Tables attached as part of the logon session - are they local to that session ie another logon can attach a different volume without trading on the toes of the first session?
I am trying to work my way thru managingb custom permissions etc.
The senario is that on a Master Menu two Menu elements - Search and LogOn/LogOut - with its menu items - are set with Permissions of "none", all other menus, submenus have a permission level of 10. and thus the the Logon part of the menu is accessable when the page is launched.
I have custom logon subroutine that checks usernae etc and retrieves permissions etc from a file as per published examples.
1. I had tried to modify the parent menu based on logOn userName - and this seems to work BUT with or without parentmenu modification, permissions donr weem to translate thru - exposing and allowing user access to other parts of menu. I havn't yet added the O4WCUSTOMPERMISSIONS to the Configuration - is this the issue?
2. When I have the login, or whatever break to debugger, and inspect @ADMIN this is set at 2 rather than what I expected of a ordinary User - is this simply an artifact of running the environment in debug mode - or is all O4W at @ADMIN=2 level?
Why do I care? Well, I have a security MFS on a table with the code set to skip if @Admin=2 (to facilitate Admin debugging).
3. Standard OI Commons that are initiated in an O4W session, are the values shared with other log-on sessions or are they local? - just want to be 100% sure.
4. Tables attached as part of the logon session - are they local to that session ie another logon can attach a different volume without trading on the toes of the first session?
Hi, Richard. I think there's some confusion that needs to be cleared up here…
When a request comes in to the web server, the registry information is retrieved by OECGI3 and a request is made to the Engine Server to log in using the credentials stored in the registry. If there is already an OEngine available to the Engine Server that has the required credentials - application, user name, and "listener" routine to run - and that OEngine isn't currently busy doing something else, then the Engine Server will submit your O4W request to that OEngine. If no other OEngine exists with all the required credentials, or none exists that are available to use, then a new OEngine is started up and logged in using the credentials supplied by the registry settings - and then when it's finished your request, the OEngine will go back into a cache so that it can be reused the next time someone needs it.
So far so good?
Now, inside O4W, we also have additional permissions and authorization that can happen, but that all happens _outside_ of the normal OpenInsight application/username login process. The OEngine is _already_ logged in to OpenInsight, with the application and username as specified in the registry. Since @ADMIN is set based on how you've defined that OpenInsight user, nothing that you do in an O4W-level login will change that - all the requests that go to the Engine Server via that same virtual directory, and that thus use the same registry settings to log into the same OpenInsight application, will have the same @ADMIN.
Hopefully this also explains the answer to your other 2 questions - standard OI commons should _never_ be used in the O4W environment (as I believe is stated in the documentation), because the same OEngine may be used by a variety of different "clients" (so long as they request the same application, using the same username, and running the same "listener" routine, as I described above). Similarly, tables that are attached at login will be attached when an OEngine is started up, and then will be seen by other clients that will "re-use" that OEngine when it's not busy. Of course, this also means that if you programmatically detached a table during your processing, then the next time someone makes a request that re-used that same OEngine, the detached table would _not_ be available to them.
So the bottom line is, if your application requires you to manually detach or attach tables, then you should be sure that you have code that runs whenever you've started processing a request that checks, and if necessary performs those table attach/detach operations, each time; and if your application requires that you put things into named common, then your application should be sure to set that named common when it starts processing (and for the security conscious, clears that common when you're _done_ processing).
Does that clear things up a bit?
- Bryan Shumsky
Thanks Bryan,
Great clarification - having set up registry stuff eons ago and currently woring wiith socket server in debug mode - kind of forgot about the UseName - which had originally been set to AppName thus @Admin=2.
Like a lot of developers with OI I have custom security system - that is the OI login is typicaly at the default USER level and then a custome login / permission assignment occurs. Seems that I can proceed n the same track with O4W, just being mindful of maintaining and passing session information.
Dynamicly attaching tables presents an interesting challenge. In my OI environment the login process is set to verify the user has the correct tables attached. If the user subsequently swap volumes the logout process returns to default. Your guidance is that at every crucial step the process should re-verify correct table attachment. That shouldnt prove a major problem - just sorting out a standard bit of code to run.
Another reason I posed these question is that I am sure there are a number of developers who are planning to offer cloud-based apps in which the client loging in would trigger the attachment of client specific volumes. THis would seem quite do-able but with some thought to processes.
Thanks for clarification. I am sure I will have a little more pain on this before I am thru.
Richard Bright
Thanks Bryan,
Great clarification - having set up registry stuff eons ago and currently woring wiith socket server in debug mode - kind of forgot about the UseName - which had originally been set to AppName thus @Admin=2.
Like a lot of developers with OI I have custom security system - that is the OI login is typicaly at the default USER level and then a custome login / permission assignment occurs. Seems that I can proceed n the same track with O4W, just being mindful of maintaining and passing session information.
Dynamicly attaching tables presents an interesting challenge. In my OI environment the login process is set to verify the user has the correct tables attached. If the user subsequently swap volumes the logout process returns to default. Your guidance is that at every crucial step the process should re-verify correct table attachment. That shouldnt prove a major problem - just sorting out a standard bit of code to run.
Another reason I posed these question is that I am sure there are a number of developers who are planning to offer cloud-based apps in which the client loging in would trigger the attachment of client specific volumes. THis would seem quite do-able but with some thought to processes.
Thanks for clarification. I am sure I will have a little more pain on this before I am thru.
Richard Bright
Hi, Richard. Glad that helped.
Indeed, I have also spoken to developers who plan to do what you've suggested - dynamically attach sets of tables depending on who the _O4W_ user is (and not the OI user, which never changes - unless you create a virtual directory, with its own set of registry settings and thus its own application/user name/password parameters, for each user, which is an alternative solution to the problem). If you go for the single OI user/multiple O4W user solution, then yes, your code must manage the table attach/detach process each time your routine gets invoked.
An alternative design might be to have multiple copies of the table attached, all name-spaced as appropriate (ie, MYTABLE_CUST1, MYTABLE_CUST2, etc.). Your procedures would open the one appropriate to the current O4W user, or - if it's not available - attach it at that time. In this way, you don't have to suffer the performance hit of detaching and attaching full sets of tables each and every time, over and over; it'll only need to happen _one_ time for each new OEngine that gets opened up. Just a thought…
- Bryan Shumsky