We’re bringing about a dozen new users online in a shared, encrypted system.
In their first run of the system, logged in as User, they’re getting frequent messages dbinfo(“procedures”) is not authorized..
View Search is not turning up any usage of dbinfo(“procedures”) so I’m not sure of the source for the error. The files do have an infrequent use of dbinfo(“folder”,“”), dbinfo(“connected”,“”), or dbinfo(“recordlockid”,“”)
Some of the procedures generating the error have no dbinfo( of any sort.
Since it works in the Administrator, I can’t easily determine where in a procedure the error is occurring. Changing my role requires that I fully log off each time.
So I have no idea how to resolve this, or to track it down. In spite of my not having used dbinfo(“procedures”), it does seem like any dbifo( should be usable in procedures regardless of the user’s role.
Hmmm, I do have some libraries that we load and places where a blueprint is altered and saved… but they don’t come up in the procedures generating the error.
No, you simply need to add additional roles to your account. You have not set up a developer password or user password for your account, so the Role menu doesn’t allow you to choose those options.
You can’t use blueprints if the database is locked down.
If a database’s structure is locked down, it’s locked down. Some of the tool cools that are available in an unrestricted database cannot be used.
By the way, the dbinfo( function that is causing the error is in the blueprint statement you are using. Unfortunately, the error message mentions the exact source of the error, even if that is not in your code. It would be nice if the error message would indicate where the problem is in your code, for example it would be nice in this case if the error message said saveblueprint not authorized instead of dbinfo( not authorized. Unfortunately, this would probably require at least months of work combing through all of Panorama’s libraries and finding every spot where an error could occur.
The Documentation is a bit thin there. I’m guessing that if I start adding passwords there, I’m effecting all the client’s copies as well. They’ve added these passwords but as one of the two Administrators on the account, any they’ve set are not showing up on my end.
Ouch! That creates a lot of backtracking where I’ve used blueprints to modify all sorts of objects.
The fact of the matter though, is that there aer a number of other times the error is popping up on the User’s machines and it’s not at all obvious about where the issue might be.
I’m assuming that screen shot was taken when you were logged in to your account. Adding passwords to your account won’t affect the client at all. Of course you don’t need developer or user passwords since you are presumably the only person using your account, but they could be handy for your testing purposes.
any they’ve set are not showing up on my end
I’m not sure what you mean by “show up” in this context. If you log on to your clients Panorama account, you can use any of their passwords, and the level you are logged in on will depend on which password you type in. If you log in using their administrator password, you should be able to use the pop-up menu to downgrade to developer or user level.
Ok, I think your original statement was correct - because what you are doing is not just changing role, you are changing to a different role in a different Panorama X account. The Role pop-up menu doesn’t change what account you are logged in to, it keeps the account the same but changes the role. So yes, you need to log off of your account and then log on to your client’s account to do that.
I’m working on a Mini that is solely logged on to the client’s account; never to my own account. I’m logged on as an Administrator, as is someone in the client’s office.
When they started running the shared file set they started getting the dbinfo(“procedures”) is not authorized in numerous situations for the staff logged in as User.
When I wanted to test as a User, there was no way for me, as an Administrator, to see what password may have been established for other roles. I didn’t know if my entry of passwords for other roles would override any passwords set at their end - although I suspect it will.
As I wrote yesterday, and again today, the error is not limited to what I’ve now determined to be three instances in which I found code regarding blueprints. They’ve probably not even touched those procedures. But the error is popping up with some frequency and I’m clueless as to what to look for.
Is there any sort of list to guide us on what a procedure can’t do in a locked down database? Just now I was unable to find any indication in Help that blueprints ( as an example ) are off limits for procedures being run by a User.
According to the documentation:
anyone logged on with the User role can open and use the database, but only Developers and Administrators can modify the design of the database (add or remove fields, edit forms and edit procedures).
It’s easy to assume that procedures Developers and Administrators will be available to Users.
I have hundreds of procedures that are now a mine field of bugs that we won’t know about until someone triggers them, and little to no ability to discover them in advance.
Perfect documentation doesn’t exist and I can hardly beat you up for the fact that it isn’t clearer; and I don’t care to. I do believe that, if it doesn’t exist, some sort of reference to the limitations for a User is warranted.
If you are logged on as an Administrator to an account that has Developer and User roles set up, you should be able to use the Role pop-up menu to switch to Developer or User role. I can see from your screen shot that you weren’t able to do that, but I don’t understand why. I do that all the time (well, not all the time, but I have done it many times). I just verified right now that it works. If you are going to a lower level it will just do it without asking for a password. You are only asked for a password when moving to a higher role, for example from User to Administrator.
Panorama will never show any password to anyone. To know what passwords are set, you’ll need to ask the client. Since you already have the admin password there should be no problem giving you the other passwords as well. But you shouldn’t need them to change the role from Administrator to a lower role.
If you are logged into the client account as an Administrator, and you go into the Site License Credentials panel and change the passwords, that will change them for anyone using the account. That’s something that you would certainly not want to do other than in close cooperation with the client.
This is going to sound pedantic, but “being logged in as User” is only indirectly causing the errors you are encountering. Being logged in as User doesn’t change anything unless the database is set to have restricted behavior when the user is logged in as a user. For example, with the entitlements shown below, users logged in as Developer or Administrator can modify the database design, but users logged in as a “User” cannot, and anyone logged into a different account cannot modify the design (no matter what role they have).
The dialog says “Can Modify Design”, but there’s a bit more to it. If the design can’t be modified, it actually means the design will be kept secret. If you are not allowed to modify the design, this also means that you cannot
get a list of the fields in the database
get a list of the procedures in the database
get a list of the forms in the database
get a list of objects in a form
get information about the attributes of an object in a form
get a list of the fileglobal variables associated with the database
This is a security measure. For example, if an attacker can get a list of the procedures in the database, they could call the procedures they found to perform unauthorized functions. If the list is unavailable, they are unlikely to be able to guess the names of procedures.
In most cases there is an alternate technique that will allow you to get your task done without access to the secret design information. For example, you might have code that checks whether a procedure exists and calls it if it does, like this:
if arraycontains(dbinfo("procedures",""),"ProcedureX",cr())
call ProcedureX
endif
But if the person running this code can’t modify the design, this code won’t work. However, there is a workaround - the procedureexists( function. This function is allowed because it doesn’t reveal the list of procedures. If you already know the name of the procedure, you are allowed to check whether it exists or not.
if procedureexists("ProcedureX")
call ProcedureX
endif
As a side bonus, this code is clearer.
Well, it has to be code that calls dbinfo(“procedures”).
First of all, obviously you need to check for any code that uses dbinfo(“procedures”). That has to be changed. Remember, you of course have to look into subroutines. If you have any libraries that you use, you need to look there also.
There is one Panorama function that uses dbinfo(“procedures”) - dbconstructormenu(. I’m sure you’re not using that anywhere.
As you determined with the View Search wizard, there are 15 built in statements in Panorama that use the dbinfo(“procedures”) function.
If you use any of these in a database that is locked down, you’ll get the not authorized error. I would be surprised if you are using anything other than saveblueprint, but this is the complete list.
Basically, if the error is: dbinfo(“procedures”) is not authorized, you need to look for
As one of the two administrators, the other role choices were dimmed. The other Administrator had created passwords for them but they were not immediately available to me. By adding passwords at my end, the choices became available, but I probably changed their access.
Which puts us back to where we started. When the error first came up I used View Search to look for dbinfo(“procedures”). Unless View Search is overlooking something, it does not occur in any of the files I’ve developed. When I switched to All Databases + Libraries it produced the list below.
I did find three places where I alter the blueprint of an object. They’re somewhat buried within the program and not where the users are encountering the error.
I’ve discovered that I can set Enable Advanced Error Dialog in the Panorama Preferences and that it will carry over into the User role.
Right away that lead me to discover a major issue, and what I can only assume is a Panorama bug.
Most, if not all, of the errors they’re experiencing are coming from .CustomMenu.
Running as a User the Error Wizard popped up with the dbinfo(“procedures”) error. It displayed the procedure which cannot be copied. But the Open arrow worked and opened _PanoramaLib:RUNCUSTOMMENU and there is the offending dbinfo({procedures}
Certainly Custom Menus should be expected to be available in the User role.
Even as a User, I was able to edit the RUNCUSTOMMENU procedure and sidestep the problem.
;if arraycontains(dbinfo({procedures},{}),{.CustomMenu},cr())
if procedureexists({.CustomMenu})
call {.CustomMenu}
else
// nsnotify “Custom Menu Error”,“Text”,info(“databasename”)+" does not contain a .CustomMenu procedure."
endif
BTW, I would hope to see the access to the Advanced Error Dialog maintained. Since it can only be set by an Administrator in the first place, it does become an obviously handy way to debug while in a ‘simulated’ User role. I think it just saved me hours of wild goose chases.
Yesterday I should have thought of searching for dbinfo(“procedures” with different string delimiters, if so, I would have found this immediately. Today I went ahead and searched for all possible delimiters, this was the only occurrence. This bug is now fixed.
I’m sorry, I should have suggested that to you yesterday. I didn’t because I thought that you weren’t able to produce this error “on command”, and that you were looking for a way to find this problem without running code (not unreasonably).
I think you probably need to blank out your mind and clear out any thoughts you currently have about what what the “user role” is. You are clearly imagining that it is a setting that affects all Panorama operation. It is not.
The only thing the role does is tell Panorama what database entitlements to use when deciding whether a particular database operation can be performed. (There is one other special entitlement for Administrators - they are allowed to use the Site License panels for changing credentials, making payments and viewing account history).
Even as a User, I was able to edit the RUNCUSTOMMENU procedure
Of course. The RUNCUSTOMMENU procedure is in the _PanoramaLib database. The _PanoramaLib database is not locked to a database, and the entitlements are set so that anyone can open it, and anyone can modify it - no matter what account they are logged in to, and no matter what role they are logged in to.
The fact that you are logged in as a user role only matters when you are using databases that are locked to the account you are logged in to. When that happens, Panorama checks your role to see what database entitlements you have.
I would hope to see the access to the Advanced Error Dialog maintained.
In this case, the Error Dialog displayed the source code where the error occurred because that source code was in an unrestricted database (_PanoramaLib). If the error had occurred in your code, the Wizard would not have shown the source code, because it doesn’t have access to the code.
In other words, access to the Error Dialog isn’t “on” or “off”, it is dependent on whether the code is in a restricted database.
Also noticed that this authorization error occurred in code that isn’t itself restricted. The entire point of this system is that a malicious programmer can’t come along and violate the rules that you have set for your database. Otherwise a programmer could come along with their own database and write code that performs operations that you want to prohibit.
Sorry this is all rather pedantic but I think it will helpful for you to understand what is actually happening here.
This is not how it is supposed to work. The list of available account roles is not kept on the local computer, it is kept on provue’s server. When the Site License window is opened it fetches the list of available roles from provue’s server, so the Role menu should be exactly same on every computer that is logged in to this account.
About 4% of Panorama accounts have multiple roles set up. That’s a small percentage but the absolute number is large enough that I would think that I would have heard about it if this didn’t work. So far I have no such reports.
Could you send me the email address of the client account involved, so that I can check to verify what roles are set up for that account? (Of course please send this in a separate email, not in a public message.)
Thanks for the lengthy response. The ability to access the lib files makes sense as well as access to Enable Advanced Error Dialog. That was a real time saver for me.
In retrospect the fact the CustomMenu was the issue, it’s no wonder that it seemed like the error was being reported to me as coming up all over the place.
There’s no clear way to track down other ‘legitimate’ Dbinfo(“procedures”) issues, but now that I know of three instances in which Blueprints are altered I can pursue a cure. All three are for a similar use in allowing the user to select and change the columns of a Text List for printing and exporting reports. I was pretty proud of the feature. I’ve been intending to extract it and add it to the Database Exchange.
I think there is. You just need to search for “procedures”, {procedures}, |procedures|, ‘procedures’ or “procedures”.
I mispoke yesterday - I told you that you could not get a list of the fields if the design is locked. That is incorrect, dbinfo(“fields”) will work. (However, it won’t be allowed if the user is not allowed to use Standard UI.)
So, I think you should be able to implement your report tool, but you won’t be able to do it with blueprints. Instead you’ll need to use dbinfo(“fields”) to get the list of fields. It might be a bit more work, but actually, I think it migh be easier. With blueprints you were getting way more information and then throwing away most of it. You can just get the information you want.
