Re: WEB DB: Problem granting priveleges other than 'Public"

[Quoted] On Thu, 13 Jul 2000 22:05:32 +0200, "Klaus Zeuch" <KZeuch_at_nospamhotmail.com> wrote:

>Create a database access descriptor DAD (e.g.: toall) and specify *both*
>user and password for that dad (e.g. scott/tiger). Grant execute privileges
>for menu and reports to scott. Call the components (e.g. menu publicmenu)
>using the dad toall in the url, e.g.:
>http://myserver/toall/scott.publicmenu.show. There's no need for login,
>cause webdb can dad toall resolve as login as scott/tiger and invoking
>package publicmenu Procedure show in the scott-schema.
>
>If you want a login from the user take a DAD without predefined
>user/password -> user must login -> to see his components he must have been
>granted execute privileges. By the way: Grant privileges to roles, not to
>users, and grant that roles to the user - makes maintenance a lot more
>easier.
>
>Hth
>
>Klaus

Hmmm.... I have two DADs for the site; one of them is a public DAD, and the other is a DAD for the 'secure' version, which prompts for a UID and password.

What I have on the site is a folder in which is a single item of content, a menu. The menu enables users to execute various reports. The menu and reports are all WebDB components. When developed, the execute priveledge on all items was granted to 'Public'.

However, what I need is to restrict access to some of the reports in the menu. Within the menu component, for each restricted item, I set the menu line to require a specific role. I then assigned that role to a user.

What I expected to happen was that when a user entered the site via a public DAD, they would not be able to see the restricted menu items, but if they specifically logged in and had the necessary role assigned, the menu item would then be visible. This is not happening.

[Quoted] Just to see what would happen, I made all menu options available to the public, and then revoked execute priveledges on the restricted reports from 'Public', and then assigned them to the role. I expected that a user who had specifically logged in and who had the role assigned would be able to execute the report; however, such a user receives the same error as a user who is not a member of the group.

[Quoted] I then tried giving execute priveledge on the report component to the specific user, but that user still received an error when specifically logged in to the secure site.

So what it looks like to me is that, even when a user is specifically logged in to the database via the 'secure' DAD, priveledges granted them via membership in a role (my preferred method by far) or granted to them directly are not recognized while they navigate the site.

What is it I'm missing??

Thanks!!