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

Klaus -

First off, I want to say 'thanks' for all the time you have taken to help me along. Thanks! I appreciate it very much.

One item in your last post caught my eye - you spoke of specifying a URL for the folder item in question (the menu component). Instead of specifying a URL when I created my item, I had specified that I wanted the item to be a WebDB Component, and then simply picked the component off of the list. What I had expected was that when a user surfed in, they would automatically be logged in as the 'public' account (via the public DAD, /mysite/), and would see only the items I allowed them as programmed into the menu component. This part worked.

To allow a user to access the restricted portions of the menu (based on their assigned roles), I had wanted to tell users to click on the 'log-in' tool on the menu bar. This would ask them for userid and password, and log them in through the 'secure' DAD (not /WEBDB/, but /mysites/). I then thought they would be able to see the restricted portions of the menu. This part didn't happen. So....

I created another item, and for this second item provided the URL of the menu, through the 'secure' DAD, i.e. /mysites/schema.menupackage.show. When I click on this item, I am asked in all cases to log-in, and based upon the userid and password, the menu component now functions as designed. Eureka!! Thanks again.

However...

Once the user has logged-in via the log-in tool in the menu bar, the URL in the browser window indicates that they are now accessing the site via the secure /mysites/ DAD. When I click on the original menu item (specified as a WebDB component), the menu doesn't work as designed, but when I click on the new item (specified as a URL through the /mysites/ DAD) it does work as designed. In both cases, the user is supposedly accessing the website via the secure /mysites/ DAD, but when the item as specified as a WebDB component, it doesn't work correctly. Is this by design, or a bug??

I had originally wanted a site where:
1. Public users didn't have to log in anywhere if they didn't want access to restricted content.
2. Authorized users could access restricted content along with public content, without having to click on separate links 3. The availability or non-availability of restricted content would be transparent to the user.

Looks like I can't achieve all three. I either have to : 1. Provide a single URL to the secure DAD, /mysites/, and force public users to log in anyway, even if they use the mysite_public userid 2. Separate public and restricted content and provide access via different links pointing to different DADs, or 3. Create two different links to the same menu, one of which specifies the public DAD, and one of which specifies the secure DAD, and mark them as such so users can choose. The public link would hide the menu options I want hid, and the secure link would provide both public and restricted content within the same menu.

Each of these options violates one or more of my objectives, though. Can you comment: is my understanding and reasoning correct??

Again, thank you very much for your assistance!

Nick Yeast

On Fri, 14 Jul 2000 09:09:19 +0200, "Klaus Zeuch" <KZeuchnospam_at_hotmail.com> wrote:

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