home *** CD-ROM | disk | FTP | other *** search
/ Monster Media 1993 #2 / Image.iso / clipper / nettos11.zip / BINDERY / XBIND.PRG < prev   
Text File  |  1992-12-04  |  5KB  |  128 lines

  1. /*
  2.  * File......: XBIND.TXT
  3.  * Author....: Steve Tyrakowski
  4.  * CIS ID....: 73766,1224
  5.  * Date......: $Date$
  6.  * Revision..: $Revision$
  7.  * Log file..: $Logfile$
  8.  * 
  9.  * This is an original work by Steve Tyrakowski and is placed in the
  10.  * public domain.
  11.  *
  12.  * Modification history:
  13.  * ---------------------
  14.  *
  15.  * $Log$
  16.  *
  17.  */
  18.  
  19.  
  20. /*  $DOC$
  21.  *  $FUNCNAME$
  22.  *     OVERVIEW
  23.  *  $CATEGORY$
  24.  *     Bindery
  25.  *  $ONELINER$
  26.  *     
  27.  *  $SYNTAX$
  28.  *
  29.  *  $ARGUMENTS$
  30.  *
  31.  *  $RETURNS$
  32.  *
  33.  *  $DESCRIPTION$
  34.  *
  35.  *   The functions that access the bindery are very powerful tools
  36.  *   for the Clipper programmer.  As Peter Parker has learned
  37.  *   after being bitten by a radioactive spider, "With great
  38.  *   power comes great responsibility."
  39.  *
  40.  *   A couple years back, when a 3rd party network library suggested
  41.  *   that they were going to add bindery update functions to their
  42.  *   product, I remember reading several messages on CompuServe
  43.  *   from people who said that such a product would not be allowed
  44.  *   in their shops because of the death  and destruction it could
  45.  *   cause.  Well this approach is utter nonsense, because Novell
  46.  *   publishes the API to access the bindery, and anyone with the API
  47.  *   could write the code to do it -- having a library function just
  48.  *   makes it easier.
  49.  *
  50.  *   Their fear is not unfounded though.
  51.  *
  52.  *   YOU CAN REALLY REALLY MESS THINGS UP BAD on your server
  53.  *   if you don't know what you are doing!!
  54.  *
  55.  *   Danger Will Robinson, Danger!!
  56.  *
  57.  *   Well then, why on earth do we want to give easy access to the
  58.  *   Netware bindery to any Clipperhead with a modem?  Because the
  59.  *   bindery is Netware's own database, and a neat example of client
  60.  *   server in action.  The bindery also has great information for
  61.  *   security for your apps.  You can base security on the GROUPS
  62.  *   in Netware, or you can make up your own property for application
  63.  *   security.
  64.  *
  65.  *   Access to the bindery is protected by Netware's own security.
  66.  *   This means that if SYSCON does not give you access to something,
  67.  *   using the NETTO API for the bindery access will not magically
  68.  *   give you access rights.  This is your first defense
  69.  *   against accidentally messing up the bindery, if the network
  70.  *   administrator hasn't given you access, you still can't change it.
  71.  *
  72.  *   But what if you are the network administrator?  Aren't you
  73.  *   walking around with a loaded pistol?  Yep pardner you sure are.
  74.  *
  75.  *   Is there any way that I can play safely with this stuff while I'm
  76.  *   learning what the bindery is all about?  Yes!  Limit your playing to
  77.  *   those functions that only READ the bindery info, not update it.
  78.  *   Actually, this is all you need to do to use the Novell groups as
  79.  *   a basis for your application security.
  80.  *
  81.  *   When you do get brave enough to try updating the bindery, you
  82.  *   should be aware of a few things:
  83.  *
  84.  *           * the bindery is a very dumb database.  You can easily
  85.  *             mess it up.  Consider testing your stuff on a test
  86.  *             file server, not a production file server.
  87.  *
  88.  *           * The bindery is a very dumb database, so SYSCON
  89.  *             does a lot of work. The SYSCON utility that
  90.  *             accesses the standard bindery properties
  91.  *             such as GROUPS_I'M_IN, and GROUP MEMBERS has to
  92.  *             keep all those things in sync.  When you add a
  93.  *             new user, it makes several updates to the bindery.
  94.  *             It creates a new object (the user itself), then it
  95.  *             adds the user to the GROUP_MEMBERS property
  96.  *             of the EVERYONE group, and it also adds the
  97.  *             EVERYONE group to the user's GROUPS_I'M_IN property.
  98.  *             That's right, just to do that it made three seperate
  99.  *             bindery update calls, and there were probably
  100.  *             more done behind the scenes.  If you plan to update
  101.  *             any of the standard properties, you need to know
  102.  *             what SYSCON expects.  Unfortunately, I've not
  103.  *             found any good documentation for this, so tread
  104.  *             with caution.
  105.  *
  106.  *  Effect of NetWare 4.0 on the Bindery
  107.  *  ------------------------------------
  108.  *
  109.  *  Although Novell will be removing the bindery in NetWare 4.0, they
  110.  *  will not be removing the API.  Novell is moving to a new, 
  111.  *  distributed system database called "Directory Services."  This 
  112.  *  will have its own API.  Novell 4.0 servers can do something called
  113.  *  "bindery emulation" where the existing bindery API functions will
  114.  *  work.  You won't be able to access the more powerful directory 
  115.  *  services stuff but your APIs should work correctly.
  116.  *
  117.  *  $EXAMPLES$
  118.  *
  119.  *  $SEEALSO$
  120.  *
  121.  *  $INCLUDE$
  122.  *
  123.  *  $END$
  124.  */
  125.  
  126. static function xbind()
  127.         return nil
  128.