Additional configuration with AccessFiles (.htaccess)
cFos PNet evaluates configuration files, called AccessFiles. By default they are named .htaccess. So called directives
therein control the behaviour of cFos PNet for the particular folder (and all subfolder thereof) where they are located.
The first .htaccess file is located in the private folder and contains all initial settings. If the a client
requests a certain url, say /test/x/file1.txt, all .htaccess files are evaluated for all folders the url
mentions. In this example first .htaccess of the private folder is evaluated, then .htaccess of
folder pub, then of folder test, then .htaccess or folder x.
All directives are cumulative,
ie. they are added or overwritten, but not deleted.
The idea behind this cumulative configuration is, that you provide a basic configuration and then give users access to folders below the pub folder. For example, you could create a folder limited under pub and give some limited user access to that folder, so he/she can publish files there. That user can then create his/her own .htaccess file, but will be limited to the basic settings you previously configured in private and/or pub.
On the web you can find a lot of good tutorials on .htaccess files, so we will be brief here.
The
following directives are supported:
| 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 _cF_Delete enable _cF_LimitDelete _cF_Put enable _cF_LimitPut The following directives can only be overwritten if AllowOverride is All : AllowOverride , AccessFileName , SSIStartTag , SSIEndTag , _cF_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.
|
| AddHandler |
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. 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. <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. |
| 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. |
| 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 ... > ... |
| 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 . |
| _cF_UserPwd |
<file location>
where cFos PNet gets the passwords to impersonate users with the
User
directive. See
User
directive above.
|
| _cF_LimitPut |
Limit the use of HTTP PUT requests:
allow HTTP PUT is always allowed disable HTTP PUT is always deactivated auth HTTP PUT is only allowed for authorized users script-auth HTTP put is not allowed but the script method http_method_allowed returns "a" (auth). If you have a script which implements PUT semantics, like an upload script, but you don't want to allow HTTP you should use this value. |
| _cF_LimitDelete |
Limit the use of HTTP DeletePut requests. As with _cF_LimitPut you can control DELETE requests with
allow
,
disable
,
auth
and
script-auth
|
| <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. |
| 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> 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 |
cFos Personal Net documentation
- Overview
- Basic setup
- Additional configuration
- Scripting reference
- Security tips
- The standard scripts
- Miscellaneous features
- Feature reference