DB User Intf Proposal
Andrew Adams
Tue May 17 16:10:58 CEST 1994
Hi all. I've been playing with a couple of ideas and wanted to run them past you all. We are all concerned with having users update and maintain their own information in various databases; routing registry dbs, contact dbs, etc. Along with this desire comes the issue of authentication. Below are some thoughts on using HTML and a WWW browser such as NCSA Mosaic as a user interface to databases. The users are probably better off in the long run if we agree on the same approach and tools. I've been investigating the possibility of using HTML+ and an HTML browser such as XMosaic as a front end for our routing registry database. For those of you who don't know about World Wide Web stuff, here's a quick glossary. HTML stands for HyperText Markup Language. HTML is a page description language which allows you to define how pages look; for example, define sections that should be in bold or italics, etc. In addition, it also allows you to create hypertext links between pages. HTML+ is the follow-on to HTML. A superset of HTML, it also defines (among other things)_input_forms_. On a unix workstation running XMosaic, these forms appear as Motif scrolled lists, text widgets, push buttons, etc. Using a well defined application programming interface, data entered into a form can be passed off to any application you write, turned into a database query (or anything else for that matter), and then the results handed back to the user in the form of a new hypertext page. HTTP is the HyperText Transfer Protocol, the application level protocol used to serve up HTML(+) docs. Httpd is the daemon which serves documents on a given machine. It's important to understand the HTML(+) & Mosaic are information _browsing_ _tools_ and not database technologies. The database technology that sits behind HTML(+)/Mosaic is independant from HTML(+)/Mosaic. Ok, having said all that, I was thinking that it might be neat to let users enter and/or browse registry info using HTML(+) and Mosaic. For example, a user could start up XMosaic and load the "Registry Info Browser" page which would prompt them for a name and password. (See paragraphs on authentication below). The name could then be used to determine the ASs for which the user is the contact, and a screen displayed which would allow them to view their AS's current policy and submit changes if necessary. To test the feasability of this approach a bit, I cobbled together a little application to basically do the operation described in the paragraph above. To run the demo you need to have a Web browser like Mosaic running on your machine. (Note that MacMosaic won't work 'cause it doesn't yet handle the 'forms' stuff.) Fire up XMosaic and click "Open..." button at the bottom of the "Document View" window. In the pop-up dialog that appears, enter http://shockwave.merit.edu/ala_htdocs/pass.html A page with "This is a test" at the top, and 'Name' and 'Password' input fields should appear. In the 'Name' field enter 'bmanning'. In the 'Passwd' field enter 'xyzman'. Then click the 'Submit Query' button. A new page should appear which begins 'Access Granted to Bill Manning'. This page should also have a list widget full of the ASs for which Bill Manning has authority. This list is the result of sending off an SQL query to our Informix AS Contacts database. Select an AS to modify, say AS 114, and then click 'Submit Query.' A new page should appear for which the heading reads "Policy for AS114". The policy for AS 114 appears below the heading in an editable text widget. The policy is simply the output of a "whois -r rrdb.merit.edu AS114" command. Here now you could change the policy, click 'Submit Query' and have the changes made to the database. So authentication is definitely an issue here. I'm still learning about this stuff but from what I understand so far, a couple of different levels of authentication are possible. The authentiation used in my little prototype above is the simplest and thus, least secure. The password and user name are sent, over the net, to an authentication program I wrote. The name is looked up in a local password file and the supplied passwd is compared with the stored, encrypted password. This is arguably as secure as telnet. (Assume for a second that putting a Web deamon, httpd, on your machine isn't a big security hole in itself. I don't know how secure httpd is.) Actually, it is arguably slightly more secure than telnet because, if I read the doc correctly, the passwd string sent from a password widget is uuencoded. Thus, anyone running a sniffer would have to explicity look for and decode this. For stricter authentication, it appears that the HTTP protocol has constructs built in which allow for Kerberos, PGP and PEM. I don't yet know exaclty how to implement a system using these facilities, having only quickly browsed the documentation. Reasons for using WWW, HTML+ and Mosaic for browse and update registry info. (1) Ease of use .... for some operations. For occasional users and for operations which don't require a lot of hand editing, a point and click interface might be easier to use. ftp'ing a large file of network numbers might still be the easiest way to do, say, network additions. (2) Software Exists Now on Multiple Platforms HTML is an IETF standard (pretty sure about this) and HTML+ is in IETF Draft form. NCSA has Mosaic clients that run on nearly all Unix workstations. (The Mac client which supports HTML+ forms is rumored to be forthcoming, as is a Window's version.) This means we need not distribute client code to handle the user interface. Thoughts? -Andy -------- Logged at Tue May 17 17:40:48 MET DST 1994 ---------
[ rr-impl Archive ]