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

See remarks

Klaus

Nick Yeast <nospam_at_bigfoot.com> schrieb in im Newsbeitrag: ko9sms09i7u6o0hbj8tnhcp53u3ung7ikv_at_4ax.com...
> 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] The nuts and bolts of WebDB are packages and execute privileges on these packages.
Menus are one package only - there are no single packages for the menu items. If you grant execute privileges on the menu to someone he can see all menu items, regardless if he can execute the objects the items are pointing to.

>
> 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.

Just be careful. Webdb consists of two products - sitebuilder and the "remainder". If you create components in the "remainder" you create packages as webdeveloper (typically using dad "webdb") and grant execute privileges on these components (packages) to database users or to roles. Roles and users are database objects. To execute these objects you have to log in and then you can run the packages.

Sitebuilder is a component using users and groups. Groups are not specified in the database, they are handled only inside sitebuilder as "individual frontend security concept". When you browse your database you won't find them.

When you create a folder / category and place a link in it pointing to a webdb component (e.g. menu), how looks your url: http://myserver/dad/owning_Schema.package_name.procedure_name Which dad are you using - webdb I assume. With that dad the user must do an additional log in. When invoking your root-page of sitebuilder as "public" user or administrator you're normally using different dad's. If you named your site mysite then you have dad's mysite for public access (user mysite_public password mysite_public) and mysites for administration purpose (no user specified). When you log in as administrator via the "secure" dad and invoke the url inside the folder (dad "webdb") you have to log in again.

Sorry if that's boring you - but I wasn't able to reproduce the situation you described. It's just a matter of dad's, so you can test execution privileges by switch through the dad's in your url to the menu / report: http://myserver/webdb/owner_schema.Menuname.show for menus or

http://myserver/webdb/owner_schema.reportname.show_parms for reports. Log on as user whom you granted execute privileges -> it should be OK or - in the case you are assigning privileges to roles - you've forgotten to assign this role to the user.

>
> 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!!
>
> --------
> Nick Yeast
> replace 'nospam' with 'club11'
Received on Fri Jul 14 2000 - 00:00:00 CEST