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
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:
TABLEStable 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
TABLESor no new pages may be inserted. The update-right needs to concern only column
TABLESso 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.
/usr/local/schtonk_userswher 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_adminwould 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.
 or accidentaly attached