[<<Previous Entry]
[^^Up^^]
[Next Entry>>]
[Menu]
[About The Guide]
OVERVIEW
------------------------------------------------------------------------------
Syntax
Arguments
Returns
Description
The functions that access the bindery are very powerful tools
for the Clipper programmer. As Peter Parker has learned
after being bitten by a radioactive spider, "With great
power comes great responsibility."
A couple years back, when a 3rd party network library suggested
that they were going to add bindery update functions to their
product, I remember reading several messages on CompuServe
from people who said that such a product would not be allowed
in their shops because of the death and destruction it could
cause. Well this approach is utter nonsense, because Novell
publishes the API to access the bindery, and anyone with the API
could write the code to do it -- having a library function just
makes it easier.
Their fear is not unfounded though.
YOU CAN REALLY REALLY MESS THINGS UP BAD on your server
if you don't know what you are doing!!
Danger Will Robinson, Danger!!
Well then, why on earth do we want to give easy access to the
Netware bindery to any Clipperhead with a modem? Because the
bindery is Netware's own database, and a neat example of client
server in action. The bindery also has great information for
security for your apps. You can base security on the GROUPS
in Netware, or you can make up your own property for application
security.
Access to the bindery is protected by Netware's own security.
This means that if SYSCON does not give you access to something,
using the NETTO API for the bindery access will not magically
give you access rights. This is your first defense
against accidentally messing up the bindery, if the network
administrator hasn't given you access, you still can't change it.
But what if you are the network administrator? Aren't you
walking around with a loaded pistol? Yep pardner you sure are.
Is there any way that I can play safely with this stuff while I'm
learning what the bindery is all about? Yes! Limit your playing to
those functions that only READ the bindery info, not update it.
Actually, this is all you need to do to use the Novell groups as
a basis for your application security.
When you do get brave enough to try updating the bindery, you
should be aware of a few things:
* the bindery is a very dumb database. You can easily
mess it up. Consider testing your stuff on a test
file server, not a production file server.
* The bindery is a very dumb database, so SYSCON
does a lot of work. The SYSCON utility that
accesses the standard bindery properties
such as GROUPS_I'M_IN, and GROUP MEMBERS has to
keep all those things in sync. When you add a
new user, it makes several updates to the bindery.
It creates a new object (the user itself), then it
adds the user to the GROUP_MEMBERS property
of the EVERYONE group, and it also adds the
EVERYONE group to the user's GROUPS_I'M_IN property.
That's right, just to do that it made three seperate
bindery update calls, and there were probably
more done behind the scenes. If you plan to update
any of the standard properties, you need to know
what SYSCON expects. Unfortunately, I've not
found any good documentation for this, so tread
with caution.
Effect of NetWare 4.0 on the Bindery
------------------------------------
Although Novell will be removing the bindery in NetWare 4.0, they
will not be removing the API. Novell is moving to a new,
distributed system database called "Directory Services." This
will have its own API. Novell 4.0 servers can do something called
"bindery emulation" where the existing bindery API functions will
work. You won't be able to access the more powerful directory
services stuff but your APIs should work correctly.
Examples
Source: N:\SRC\BINDERY\XBIND.PRG
Author: Steve Tyrakowski
This page created by ng2html v1.05, the Norton guide to HTML conversion utility.
Written by Dave Pearson