Next: , Previous: Modes of deployment, Up: Top


4 User identification

Schtonk relies on httpd in user identification. If httpd identifies the user, it passes the username to g.tcl using CGI. In apache it is done by saying

     	ScriptAlias /cgi-bin/ /usr/local/schtonk/
     	<Directory "/usr/local/schtonk">
     		AllowOverride None
     		Options +ExecCGI -MultiViews +SymLinksIfOwnerMatch
     		Order allow,deny
     		Allow from all
     		AuthType Basic
     		AuthName "Password Required"
     		AuthUserFile /etc/schtonk.password.file
     		Require valid-user
     		SSLRequireSSL
     	</Directory>

somewhere inside your VirtualHost directive. By this example there directory for g.tcl would be /usr/local/schtonk and the password file that is kept with command htpasswd of apache is in /etc/schtonk.password.file but for security for obscurity reasons it might be good idea to store them somewhere else.
Idea of this setup is to keep out those who are not listed in /etc/schtonk.password.file.
Reason for that is that schtonk, by giving access to database, grants quite much power to users to change and update and delete and generally do anything with the data in the db. This may be limited by means provided by MySQL or other db backend that might be in place but there's some drawbacks:

  1. By allowing user access to data the very (knowledgeable) users may themselves alter the algorithms how data is processed ; this thing may be revoked but the good idea of allowing users to modify the way how data is processed is lost.
  2. Old MySQL versions do not allow very fine-grained access control. MySQL5 seems to support column-level access control. It is possible to set certain tables to be read-only for, for example, set TABLES table to be read-only or insert-only (still allowing new versions to be created) and not render schtonk totally un-usable. Current implementation requires (for performance reasons) insert AND update rights to table TABLES or no new pages may be inserted. The update-right needs to concern only column IS_LATEST in table TABLES so granting user schtonk right to insert new rows and update this one column allows users to fully exploit the wiki-nature of schtonk. Again it is possible to revoke update and delete rights regardign table ATTACHMENTS, making it more difficult for users to remove existing1 attachment files.
  3. Right now backend.tcl has one database connection. No matter what http username user uses to connect her httpd client to httpd, the schtonk backend.tcl will anyway use a common database connection for all connected users, thus sharing the database access rights among all the users.

So you better trust your users.

That said, it is entirely possible to have one copy of g.tcl in /usr/local/schtonk_users wher g.tcl will be identified by httpd with one username list and that connects to backend.tcl listening in, say, port 32000. In addition it is possible to have /usr/local/schtonk_admin, having different script-alias directive in apache-configuration, having different password list, g.tcl invoked from /usr/local/schtonk_admin would connect to backend.tcl listening at tcl port 32001 and by that way it might be possible to have schtonk running so that there would be 2 backend.tcl instances, having different access rights to database. This is doable, but a bit awkward and not elegant.

Footnotes

[1] or accidentaly attached