cFos Personal Net-documentatie - Aanvullende configuratie

Aanvullende configuratie met AccessFiles (.htaccess)

cFos PNet evalueert configuratiebestanden, AccessFiles genaamd. Standaard heten ze .htaccess. Zogenaamde richtlijnen bepalen daarin het gedrag van cFos PNet voor de specifieke map (en alle submappen daarvan) waar deze zich bevinden. De eerste .htaccess bestand bevindt zich in de private map en bevat alle oorspronkelijke instellingen. Als de client om een bepaalde url vraagt, zeg /test/x/file1.txt, worden alle .htaccess bestanden geëvalueerd voor alle mappen die de url vermeldt. In dit voorbeeld is de eerste .htaccess van de private map wordt geëvalueerd, dan .htaccess van de map pub, dan van de map test, dan .htaccess van de map x.
Alle richtlijnen zijn cumulatief, dat wil zeggen. ze worden toegevoegd of overschreven, maar niet verwijderd.

Het idee achter deze cumulatieve configuratie is dat u een basisconfiguratie opgeeft en vervolgens gebruikers toegang geeft tot mappen onder de pub. U kunt bijvoorbeeld een map maken die beperkt is onder pub en wat beperkte gebruikerstoegang geven tot die map, zodat hij/zij daar bestanden kan publiceren. Die gebruiker kan vervolgens zijn/haar eigen .htaccess bestand maken, maar is beperkt tot de basisinstellingen die u eerder in private en/of pub hebt geconfigureerd.

Op internet kun je veel goede tutorials vinden over .htaccess bestanden, dus we zullen het hier kort houden.

De volgende richtlijnen worden ondersteund:

AllowOverride	Enables/disables certain groups of directives in .htaccess. Values are: All all directives can be changed Indexes enable DirectoryIndex FileInfo enable ErrorDocument, AddType, AddHandler, RemoveType, RemoveHandler, DefaultType, Redirect, RedirectPermanent, RedirectTemp AuthConfig enable AuthUserFile, Require, AuthGroupFile, AuthName, AuthType UserInfo enable User The following directives can only be overwritten if AllowOverride is All: AllowOverride, AccessFileName, SSIStartTag, SSIEndTag, PNet_UserPwd.
AccessFileName	The <name> of the AccessFile, default: .htaccess.
DirectoryIndex	<file> which is served, if the clients specifies a folder, like /. Many configurations use index.htm/index.html here.
ErrorDocument	[<num>] document If HTTP error <num> is encountered, which error document is served. If <num> is ommited the document is used for all errors.
AddType	Add a <MIME type>, see mime.types in the private folder.
RemoveType	Remove a <MIME type>
DefaultType	What <MIME type> should be used, after searching the MIME types added with AddType and then searching the mime.types file in vain.
ForceType	Forces the mime type to <MIME type>, regardless of the file extension.
AddHandler	mode <ext> if a files with extension <ext> is requested, what should cFos PNet do with it. Values for mode are: type-map / default-handler this is the default. Files are simply send to the client. The type is determined by the MIME type. server-parsed this is a server-side include file. cFos PNet parses the file before sending and supports the following SSI (shtml) directives: echo, include. For an example see the all_errors.shtml file in the private folder. cFos PNet also supports nested includes and script invokation by the SSI include directive. cgi-script CGI script. An external program in started and the process environment is set appropriately. Also this process runs under the user impersonation configured previously. So you can run your favourite scripting languages (Perl, PHP, etc.) in a secure context. fast-cgi Use a FastCGI script. The FastCGI script is started on first use and ended when the server is stopped. java-script Built-in Javascript. cFos PNet offers some extensions and a webserver object to allow seamless integration of Javascript and the webserver. See the scripting documentation below. php-file Like cgi-script, but use the key "php_interpreter" in the [param] section of GLOBAL.INI to start the (PHP-)interpreter with the PHP script file as command-line parameter. Use the full path and optional command line options of PHP-CGI.EXE here. <script language name> cFos PNet uses the windows scripting host for script execution. Therefore you can use any scripting language which supports the scripting host. Use the language name as registered with the scripting host for <script language name>, e.g. "Jscript" for Javascript or "VBScript" for Visual Basic Script.
RemoveHandler	Remove a previously added <handler>.
Redirect	Redirect a certain <url> to another.
RedirectPermanent	Redirect a certain <url> to another.
RedirectTemp	Redirect a certain <url> to another.
RedirectMatch	Redirect a certain <url> to another.
PNet_redirect_host <status> <regex> <dest>	redirect according to the host part in a HTTP request (e.g. in http://www.cfos.de/dl the host part is www.cfos.de). <status> is either an HTTP response code or permanent (301), temp (302), seeother (303) or gone (410). <regex> is a regular expression as in the RedirectMatch directive. <dest> is the destination host. The redirect location is the HTTP protocol + <dest> + original URL + original query string. This directive allows easy mapping to a canonical host, e.g. redirect all requests to cfos.de to www.cfos.de.
SSIStartTag	How server side include directives start, default <!--#
SSIEndTag	How server side include directives start, default -->
AuthType	Type of authorization to access the current folder and all its sub-folders: basic Username and Password are transmitted as clear-text. digest Instead of a clear-text password, a digest value is calculated and transmitted. Thereby an attacker cannot read the password. This method is also secure against re-play attacks, because one digest values cannot be used twice. Note: cFos PNet can also use HTTP authorization from Javascript. This may eliminate the need for session tracking / session cookies in many cases. See below for more information.
Require	Which authorization entity is required: user <x> The user named <x> must be authorized to access content in the folder. group <x> The user must be in group <x> to access the content. valid-user Any valid user can access the content. actual-user A valid user, where the last path part matches the user name (e.g. /private/test/index.htm matches user name test). all granted Always allow access all denied Always deny access, answer the HTTP request with a 403 Forbidden response. method <method-list>method-list is a space-separated list of HTTP methods. Only allow access if the current HTTP methods is one of the methods specified in the method list, e.g. GET, POST, PUT, etc. env <environment-var-list>environment-var-list is a space-separated list of environment variables. Only allow access if one of the listed environment variables is defined and not empty.
AuthName	The <name> of the authorization realm. This is the name, the browser displays in the password window. It is also evaluated by the browser to re-use the username/password for subsequent authorization requests. By choosing a common name, you can allow the browser to authorize the user automatically for different urls / content locations within your site.
AuthUserFile	<file or folder location> of user information. If it is a file, the format is (Apache compatible) as follows: user1:password1 user2:password2 ... If it is a folder, cFos PNet assumes there is a sub-folder for each individual user, which contains a file profile.txt. profile.txt is actually a hash list (see hash list description below). The idea is to allow more profile information be stored for an individual user, for example access control lists, etc.
AuthGroupFile	<file location> of the file with (Apache compatible) group information. The group file has the following format: group1: member1 member2 member3... group2: member4 member5 ... > ...
PNet_lock <on/off>	if on use a named lock to prevent several concurrent HTTP requests from accessing resources in this directory or its subdirectories. This is useful for WEBDAV/CALDAV requests to prevent users from overwriting data with concurrent requests. You could also use it in directories, where simultaneous write access (e.g. HTTP PUT) can occur.
User	Impersonate a certain <user>. Thereby you can enforce certain user rights (restricted or extented) for certain folders. You can (and should) create at least one limited windows users, so that cFos PNet won't run under admin rights. Store the password of the limited user(s) in the file pwd.txt in the private folder, like this: "PNet_user", "!pass" assuming the user name is PNet_user and the password is pass.
PNet_UserPwd	<file location> where cFos PNet gets the passwords to impersonate users with the User directive. See User directive above.
<Files exp>	The directives in the <Files> ... </Files> are only used for files matching exp. exp can either be a filename including wildcards the * and ? or a regular expression, preceeded by ~ and enclosed in quotes, like <Files ~ "\.(gif\|jpe?g\|png\|bmp)$">.
</Files>	End of <Files> block.
<FilesMatch regexp>	Like <Files> directive, regular expression only version.
</FilesMatch>	End of <FilesMatch> block.
<Location exp>	The directives between <Location exp> and </Location> are only used for a URL which matches exp. The location directive matches the whole URL beginning with / of the request and is not tied to particular files or directories in your file system. The <Location> and <LocationMatch> directives are useful if you want to keep out .htaccess files from certain directories. In this case you can place your needed .htaccess directives in the .htaccess file of the upper directory in a <Location> or <LocationMatch> block.
<LocationMatch regexp>	Like <Location> directive, regular expression only version.
<Limit method-list>	method-list is a space-separated list of HTTP methods. Directives between <Limit method-lst>...</Limit> are only used if the current HTTP request uses one of the methods specified in the method list, e.g. GET, POST, PUT, etc.
</Limit>	End of <Limit> block.
Rewrite engine:
RewriteScript	<script-file> Rewrite engines are used to modify parts of the HTTP request before the actual request is executed by the server. cFos PNet has a Javascript based rewrite engine, which is so powerful, you could even implement a whole http server in Javascript on your own. You can modify every part of the HTTP request or even handle the whole request by your Javascript. See rewrite_doc.txt for a detailed documentation.
Cross-domain scripting support:
PNet_accesscontrolalloworigin	<list> can either be * or a space separated list of domains (which may contain the wildcards * and ?). When cFos PNet receives an Origin HTTP header it checks it against <list>. If the Origin matches one of the list elements it sends back an Access-Control-Allow-Origin HTTP header. It tells the browser to allow cross site scripting with this server, see https://developer.mozilla.org/en/HTTP_access_control for a detailed explanation.
common.js module support:
PNet_add_module_path	<list> cFos PNet supports the common.js module specification. This allows structuring Javascript code / libraries into modules. This directive allows setting a list of space separated search paths. They are used to load modules with the require function, see http://www.commonjs.org/specs/modules/1.0/ for a detailed explanation of this kind of module handling.
Data compression:	cFos PNet supports gzip and deflate data compression. Since compression may cause CPU load and/or memory consumption you should prefer smaller compression levels / memory levels and window sizes. Higher values may only gain you another few percent of extra compression at the cost of CPU and memory usage. Experiment until you find a reasonable compromise.
SetOutputFilter	deflate enable gzip and deflate compression, off = disable
DeflateCompressionLevel	val> set compression level from 1 .. 9 (1 = less compression, 9 max. compression).
DeflateMemLevel	<val> set compression memory level from 1 .. 9 (1 = less memory, 9 max memory usage).
DeflateWindowSize	<val> set compression window size from 1 .. 15 (1 = min. window, 15 = max. window).
PNet_DeflateMinimumSize	<size> disable compression for files below size.
Expiry:	Controls the sending of HTTP expire headers. Using expire headers gives you control how long browsers may cache files, before requesting them again from the web server. A good general rule is to cache images for one day and versioned scripts and CSS files (like jquery.1.6.2.min.js) "indefinitly", because when they change, they get a new version number in the filename. html files should not use an expire header, ie. they are controlled by the last-modified header by the browser.
ExpiresActive	on = enable expires headers, off = disable
FileETag	all = send Etag header, none = disable
ExpiresDefault	<exp> default expiry duration <exp> has the following format: <start> [plus] <number> <unit>, where <start> is either access, now or modification. If <start> is modification, the last modified time/date of the file is used, otherwise the the time of access (ie. when it is requested). plus is optional. <number> is any valid number for <unit>. <unit> is one of the following time units years, months, weeks, days, hours, minutes or seconds. <exp> can have the following alternative format: An or Mn, where A means "access" and M means modification. n is the number of seconds added to the <start> time. Expiration times should not exceed 1 year.
ExpiresByType	<mime-type> <exp> set expiry for a certain mime-type