- From: <dreano@capstone.nalda.navy.mil>
- Date: Wed, 19 Apr 1995 08:35:27 -0400 (EDT)
- To: "Micalizzi, Kevin" <micalizzi@concord6.powersoft.com>
- Cc: Multiple recipients of list <www-rdb@www10.w3.org>
A few tips/lessons learned: Check out GSQL from ftp.ncsa.uiuc.edu...it is a Sybase-to-WWW interface. It works for the simpler stuff but rapidly becomes cumbersome for more complex queries. We used an Oracle version of it for a while but became disenchanted when we had to perform joins (GSQL does NOT support joins), so we switched to strictly Perl, C-SQL and HTML. Can't speak for SyBase but for Oracle, connects/disconnects are not a problem. It is important to run httpd in STANDALONE mode as an INETD setup has too much overhead for multiple rapid-fire requests. Efficient interfaces are usually not the problem (the above strategy works extremely well for us) and the time spent in a) server code, b) CGI execution, c) database access and d) HTML generation is usually in the noise level when compared to network response times, assuming a well-designed database of course! We basically have a single user (the owner of the httpd server) who performs all requests on behalf of legitimate users. We modified Mosaic (X version) and both the NCSA httpd server to implement an obscure part of the URL spec to include a user's id (which is generated from a client's UNIX LOGNAME variable that he can NOT normally modify) within the URL e.g. kevin@http://www.ncsa.uiuc.edu/SDG/Mosaic.html (There IS an RFC that supports remote identification but can potentially double your network traffic and requires an extra client daemon.) The above scheme allows the server's REMOTE_IDENT CGI script variable (this server variable is normally set to 'UNKNOWN') to be concatenated to the REMOTE_HOST CGI script variable to create a compound unique key e.g. kevin <--> concord6.powersoft.com into an Oracle USER_INFO 'scratch-pad' table that contains a user's default settings and other information thus allowing the single httpd server owner/Oracle user to have knowledge of who is executing a script. (There is also a default 'adhoc' user-id that allows generic system usage with reasonable default settings thus avoiding the registration of hundreds of database users within the database engine.) This works for us because we have a READ ONLY database (except for the USER_INFO table!), no user updates are allowed. It also disables most other WWW browsers that have NOT implemented the above URL spec. (Including MS-Windows Mosaic unfortunately...I wish the developers would implement the above URL feature..someone had told me that NetScape seems to work with the above scheme, kind of!) We actually consider this last item as a small amount of additional security since we serve a well-defined, limited user community. An enhancement that we are considering is encrypting the user-id in the above URL with DES or crypt() just so it is not plain text. Frank Dreano On Tue, 18 Apr 1995, Micalizzi, Kevin wrote: > > > I'm in the process of generating a proposal for "automating" our WWW Site > so, for the most part, HTML will be automatically generated based on > information contained in a Sybase System 10 SQL Server. Some issues I > haven't addressed yet have to do with finding the most efficient interface, > and minimizing the overhead of connect/disconnects from the server for each > CGI script. Has anyone worked with a similar scenario who is willing to > share with me what you've encountered? Recommendations? > > TIA > > -Kevin P. Micalizzi >
Received on Wednesday, 19 April 1995 03:38:59 UTC