incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "George, Kenneth V [NTK]" <Kenneth.V.Geo...@sprint.com>
Subject RE: Profile Security NOT WORKING!!!
Date Mon, 28 Mar 2011 19:44:11 GMT
Yeah, I discovered that after I sent the email....sorry.

Basically, I just ran the SecurityConfig.jsp and ALL areas are GREEN.   Is this correct for a restricted site?

I only want Anonymous/Asserted to VIEW certain pages and restrict VIEW/EDIT/MODIFY/etc. to Authenticated users.

Like I said earler, this WAS working fine, but even after re-downloading 2.8.4 from the JSPWiki site, this still does not work even on different machines.  I have read through the JSPWiki security docs several times and cannot seem to find out why this is happening and if I am doing anything wrong.

-----Original Message-----
From: Harry Metske [mailto:harry.metske@gmail.com]
Sent: Monday, March 28, 2011 2:40 PM
To: jspwiki-user@incubator.apache.org
Subject: Re: Profile Security NOT WORKING!!!

George,

the intention of my reply was that you would have a look the output of
SecurityConfig.jps yourself and judge if it is what you have configured or
not.
Simply dumping the (fairly unreadable) output on the list is not the best
way to get support from volunteers.

See for example : http://www.catb.org/~esr/faqs/smart-questions.html

kind regards,
Harry


2011/3/28 George, Kenneth V [NTK] <Kenneth.V.George@sprint.com>

> Ok, done that!
>
>
>
> Here is the output:
>
>
> JSPWiki Security Configuration Verifier
> This page examines JSPWiki's security configuration and tries to determine
> if it is working the way it should. Although JSPWiki comes configured with
> some reasonable default configuration settings out of the box, it's not
> always obvious what settings to change if you need to customize the
> security... and sooner or later, just about everyone does.
> This page is dynamically generated by JSPWiki. It examines the
> authentication, authorization and security policy settings. When we think
> something looks funny, we'll try to communicate what the issue might be, and
> will make recommendations on how to fix the problem.
> Please delete this JSP when you are finished troubleshooting your system.
> This diagnostic data presented on this page do not represent a security risk
> to your system per se, but they do provide a significant amount of
> contextual information that could be useful to an attacker. This page is
> currently unconstrained, which means that anyone can view it: nice people,
> mean people and everyone in between. You have been warned. You can turn it
> off by setting
>  jspwiki-x.securityconfig.enable=false
> in your jspwiki.properties.
> Authentication Configuration
> Container-Managed Authentication
> Container-managed authentication appears to be disabled, according to your
> WEB-INF/web.xml file.
> JAAS Login Configuration
> JSPWiki wires up its own JAAS to define the authentication process, and
> does not rely on the JRE configuration. By default, JSPWiki configures its
> JAAS login stack to use the UserDatabaseLoginModule. You can specify a
> custom login module by setting the jspwiki.loginModule.class property in
> jspwiki.properties.
> The JAAS login configuration is correctly configured if the
> jspwiki.loginModule.class property specifies a class we can find on the
> classpath. This class must also be a LoginModule implementation. We will
> check for both conditions.
> Good news:
>
>  *   The property 'jspwiki.loginModule.class' specified the class
> 'com.ecyrd.jspwiki.auth.login.UserDatabaseLoginModule.'
>  *   We found the the class
> 'com.ecyrd.jspwiki.auth.login.UserDatabaseLoginModule' on the classpath, and
> it is a LoginModule implementation. Good!
> Authorization Configuration
> Container-Managed Authorization
> Container-managed authorization appears to be disabled, according to your
> WEB-INF/web.xml file.
> Security Policy
> JSPWiki's authorizes user actions by consulting a standard Java 2 security
> policy file. By default, JSPWiki installs its local security policy file at
> startup time. This policy file is independent of your global, JVM-wide
> security policy, if you have one. When checking for authorization, JSPWiki
> consults the global policy first, then the local policy.
> Let's validate the local security policy file. To do this, we parse the
> security policy and examine each grant block. If we see a permission entry
> that is signed, we verify that the certificate alias exists in our keystore.
> The keystore itself must also exist in the file system. And as an additional
> check, we will try to load each Permission class into memory to verify that
> JSPWiki's classloader can find them.
> Good news:
>
>  *   The security policy
> '/opt/tomcat/apache-tomcat-7.0.6/webapps/wiki/WEB-INF/jspwiki.policy'
> exists.
>  *   The security policy looks fine.
> We found some potential problems with your configuration: Policy file does
> not have a keystore... at least not one that we can locate. If your policy
> file does not contain any 'signedBy' blocks, this is probably ok.
> Access Control Validation
> Security Policy Restrictions
> Now comes the really fun part. Using the current security policy, we will
> test the PagePermissions each JSPWiki role possesses for a range of pages.
> The roles we will test include the standard JSPWiki roles (Authenticated,
> All, etc.) plus any others you may have listed in the security policy. In
> addition to the PagePermissions, we will also test the WikiPermissions. The
> results of these tests should tell you what behaviors you can expect based
> on your security policy file. If we had problems finding, parsing or
> verifying the policy file, these tests will likely fail.
> The colors in each cell show the results of the test.  Green  means
> success;  red  means failure. Hovering over a role name or individual cell
> will display more detailed information about the role or test.
> Permission
>
> All
>
> Anonymous
>
> Asserted
>
> Authenticated
>
> Admin
>
> Admin
>
> v
>
> e
>
> m
>
> r
>
> d
>
> v
>
> e
>
> m
>
> r
>
> d
>
> v
>
> e
>
> m
>
> r
>
> d
>
> v
>
> e
>
> m
>
> r
>
> d
>
> v
>
> e
>
> m
>
> r
>
> d
>
> v
>
> e
>
> m
>
> r
>
> d
>
> PagePermission "INSD Projects Wiki:Main"
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> PagePermission "INSD Projects Wiki:Index"
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> PagePermission "INSD Projects Wiki:GroupTest"
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> PagePermission "INSD Projects Wiki:GroupAdmin"
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> GroupPermission "INSD Projects Wiki:Admin"
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> GroupPermission "INSD Projects Wiki:TestGroup"
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> GroupPermission "INSD Projects Wiki:Foo"
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
>
> WikiPermission "INSD Projects Wiki","createGroups"
>
>
>
>
>
>
>
>
>
>
>
>
>
> WikiPermission "INSD Projects Wiki","createPages"
>
>
>
>
>
>
>
>
>
>
>
>
>
> WikiPermission "INSD Projects Wiki","login"
>
>
>
>
>
>
>
>
>
>
>
>
>
> WikiPermission "INSD Projects Wiki","editPreferences"
>
>
>
>
>
>
>
>
>
>
>
>
>
> WikiPermission "INSD Projects Wiki","editProfile"
>
>
>
>
>
>
>
>
>
>
>
>
>
> AllPermission "INSD Projects Wiki"
>
>
>
>
>
>
>
>
>
>
>
>
>
> Important: these tests do not take into account any page-level access
> control lists. Page ACLs, if they exist, will contrain access further than
> what is shown in the table.
> User and Group Databases
> User Database Configuration
> The user database stores user profiles. It's pretty important that it
> functions properly. We will try to determine what your current UserDatabase
> implementation is, based on the current value of the jspwiki.userdatabase
> property in your jspwiki.properties file. In addition, once we establish
> that the UserDatabase has been initialized properly, we will try to add
> (then, delete) a random test user. If all of these things work they way they
> should, then you should have no problems with user self-registration.
> Good news:
>
>  *   UserDatabase is of type 'com.ecyrd.jspwiki.auth.user.XMLUserDatabase'.
> It appears to be initialized properly.
>  *   The user database contains 18 users.
>  *   The user database allows new users to be created, as it should.
>  *   The user database allows users to be deleted, as it should.
>  *   The user database configuration looks fine.
> Group Database Configuration
> The group database stores wiki groups. It's pretty important that it
> functions properly. We will try to determine what your current GroupDatabase
> implementation is, based on the current value of the jspwiki.groupdatabase
> property in your jspwiki.properties file. In addition, once we establish
> that the GroupDatabase has been initialized properly, we will try to add
> (then, delete) a random test group. If all of these things work they way
> they should, then you should have no problems with wiki group creation and
> editing.
> Good news:
>
>  *   GroupDatabase is of type
> 'com.ecyrd.jspwiki.auth.authorize.XMLGroupDatabase'. It appears to be
> initialized properly.
>  *   The group database contains 5 groups.
>  *   The group database allows new groups to be created, as it should.
>  *   The group database allows groups to be deleted, as it should.
>  *   The group database configuration looks fine.
>
>
>
>
>
> -----Original Message-----
> From: Harry Metske [mailto:harry.metske@gmail.com]
> Sent: Monday, March 28, 2011 2:14 PM
> To: jspwiki-user@incubator.apache.org
> Subject: Re: Profile Security NOT WORKING!!!
>
>
>
> George,
>
>
>
> something must have been changed, but maybe you can start by pointing your
> browser at admin/SecurityConfig.jsp, that will tell you how your security
> settings are.
>
> You should first enable it by adding "jspwiki-x.securityconfig.enable=true"
>
> to jspwiki.properties and recycle JSPWiki.
>
>
>
> regards,
>
> Harry
>
>
>
>
>
> 2011/3/28 George, Kenneth V [NTK] <Kenneth.V.George@sprint.com<mailto:
> Kenneth.V.George@sprint.com>>
>
>
>
> > Good morning.
>
> >
>
> > Over the weekend, it looks as if my policy is now being ignored and
>
> > users can do anything they want to my wiki.  I found this strange, so
>
> > I decided to re-install the wiki to a local machine and found that the
>
> > jspwiki.policy file is being loaded (evidenced in the jspwiki.log
>
> > file), but the settings ARE being ignored.  If I connect to the wiki I
>
> > installed locally with the modified jspwiki.policy file, I can still
>
> > edit & create pages WITHOUT having to be logged-in.
>
> >
>
> > I am in serious need of assistance with this as unauthorized users can
>
> > get access to sensitive data and may force me to shut-down the wiki
> permanently.
>
> >
>
> > Here is my server configuration:
>
> >
>
> > JAVA Version 1.6.0_24
>
> > Tomcat 6.0
>
> > JSPWiki 2.8.4
>
> >
>
> > Here is my jspwiki.policy file:
>
> >
>
> > // $Id: jspwiki.policy,v 1.23 2007-07-06 10:36:36 jalkanen Exp $ // //
>
> > This file contains the local security policy for JSPWiki.
>
> > // It provides the permissions rules for the JSPWiki // environment,
>
> > and should be suitable for most purposes.
>
> > // JSPWiki will load this policy when the wiki webapp starts.
>
> > //
>
> > // As noted, this is the 'local' policy for this instance of JSPWiki.
>
> > // You can also use the standard Java 2 security policy mechanisms //
>
> > to create a consolidated 'global policy' (JVM-wide) that will be
>
> > checked first, // before this local policy. This is ideal for
>
> > situations in which you are // running multiple instances of JSPWiki
>
> > in your web container.
>
> > // To set a global security policy for all running instances of
>
> > JSPWiki, // you will need to specify the location of the global policy
>
> > by setting the // JVM system property 'java.security.policy' in the
>
> > command line script // you use to start your web container. See the
>
> > documentation // pages at
>
> > http://doc.jspwiki.org/2.4/wiki/InstallingJSPWiki. If you // don't
>
> > know what this means, don't worry about it.
>
> > //
>
> > // Also, if you are running JSPWiki with a security policy, you will
>
> > probably // want to copy the contents of the file
>
> > jspwiki-container.policy into your // container's policy. See that
>
> > file for more details.
>
> > //
>
> > // ------ EVERYTHING THAT FOLLOWS IS THE 'LOCAL' POLICY FOR YOUR WIKI
>
> > ------
>
> >
>
> > // The first policy block grants privileges that all users need,
>
> > regardless of // the roles or groups they belong to. Everyone can
>
> > register with the wiki and // log in. Everyone can edit their profile
>
> > after they authenticate.
>
> > // Everyone can also view all wiki pages unless otherwise protected by
>
> > an ACL.
>
> > // If that seems too loose for your needs, you can restrict
>
> > page-viewing // privileges by moving the PagePermission 'view' grant
>
> > to one of the other blocks.
>
> >
>
> > //grant principal com.ecyrd.jspwiki.auth.authorize.Role "All" {
>
> > //    permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:*",
>
> > "view";
>
> > //    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*",
>
> > "editPreferences";
>
> > //    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*",
>
> > "editProfile";
>
> > //    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*",
>
> > "login";
>
> > //};
>
> >
>
> >
>
> > // The second policy block is extremely loose, and unsuited for
>
> > public-facing wikis.
>
> > // Anonymous users are allowed to create, edit and comment on all pages.
>
> > //
>
> > // Note: For Internet-facing wikis, you are strongly advised to remove
>
> > the // lines containing the "modify" and "createPages" permissions;
>
> > this will make // the wiki read-only for anonymous users.
>
> >
>
> > // Note that "modify" implies *both* "edit" and "upload", so if you
>
> > wish to // allow editing only, then replace "modify" with "edit".
>
> >
>
> > grant principal com.ecyrd.jspwiki.auth.authorize.Role "Anonymous" {
>
> >    permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:*",
>
> > "view"; };
>
> >
>
> >
>
> > // This next policy block is also pretty loose. It allows users who
>
> > claim to // be someone (via their cookie) to create, edit and comment
>
> > on all pages, // as well as upload files.
>
> > // They can also view the membership list of groups.
>
> >
>
> > // Authenticated users can do most things: view, create, edit and //
>
> > comment on all pages; upload files to existing ones; create and edit
>
> > // wiki groups; and rename existing pages. Authenticated users can
>
> > also // edit groups they are members of.
>
> >
>
> > //grant principal com.ecyrd.jspwiki.auth.authorize.Role "Authenticated" {
>
> > //    permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:*",
>
> > "modify,rename";
>
> > //    permission com.ecyrd.jspwiki.auth.permissions.GroupPermission
> "*:*",
>
> > "view";
>
> > //    permission com.ecyrd.jspwiki.auth.permissions.GroupPermission
>
> > "*:<groupmember>", "edit";
>
> > //    permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*",
>
> > "createPages,createGroups";
>
> > //};
>
> >
>
> >
>
> > // Administrators (principals or roles possessing AllPermission) //
>
> > are allowed to delete any page, and can edit, rename and delete //
>
> > groups. You should match the permission target (here, 'JSPWiki') //
>
> > with the value of the 'jspwiki.applicationName' property in //
>
> > jspwiki.properties. Two administative groups are set up below:
>
> > // the wiki group "Admin" (stored by default in wiki page GroupAdmin)
>
> > // and the container role "Admin" (managed by the web container).
>
> >
>
> > grant principal com.ecyrd.jspwiki.auth.GroupPrincipal "Admin" {
>
> >    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*"; };
>
> > grant principal com.ecyrd.jspwiki.auth.authorize.Role "Admin" {
>
> >    permission com.ecyrd.jspwiki.auth.permissions.AllPermission "*"; };
>
> >
>
> > And here is my jspwiki.properties file (local)
>
> >
>
> > ######################################################################
>
> > #####
>
> > #
>
> > #  This is the JSPWiki configuration file.  You'll need to edit this #
>
> > a bit.  The first few lines are the most important ones.
>
> > #
>
> > #  Wherever it is said that an option can be "true" or "false", you
>
> > can #  also use "yes"/"no", or "on/off".  Just for some convenience.
>
> > #
>
> > #
>
> > #  You can use this to override the default application name.  It
>
> > affects #  the HTML titles and logging, for example.  It can be
>
> > different from #  the actual web name (http://my.com/mywiki) of the
>
> > application, but usually #  it is the same.
>
> > #
>
> > jspwiki.applicationName =JSPWiki
>
> >
>
> > #
>
> > #  Describe where your wiki lives (the real URL through which it is
>
> > available #  through the internet/intranet).  This is a mandatory
>
> > attribute.
>
> > #
>
> > #  Be careful if you use a localhost address (http://localhost/ or
>
> > http://127.0.0.1/), #  as this will cause some unwanted side effects
>
> > if your wiki is accessed from #  any other computer than where the
>
> > wiki is running.
>
> > #
>
> > #  Example:
>
> > #  jspwiki.baseURL = http://www.jspwiki.org/ #
>
> > jspwiki.baseURL=http://localhost:8080/wiki/
>
> >
>
> > #
>
> > #  Which page provider class to use.  Possibilities are:
>
> > #
>
> > #    RCSFileProvider        - for simple RCS-based file storage
>
> > #    FileSystemProvider     - for simple pure file storage with no
> version
>
> > information
>
> > #    VersioningFileProvider - for simple, non-RCS based versioning
> storage.
>
> > #
>
> > #  Note that if you're upgrading from JSPWiki 1.x, then you need to
>
> > remove the #  "com.ecyrd.jspwiki." part from the beginning of the
>
> > path.
>
> > #
>
> > jspwiki.pageProvider =VersioningFileProvider
>
> >
>
> > #
>
> > # How to order pages in various lists and plugins.  By default, they
>
> > are # ordered using Java's "natural" String order (purely character by
>
> > character # comparison). This means that the pages named "Page1",
>
> > "Page2" and "Page10"
>
> > # appear in the order "Page1", "Page10", "Page2".
>
> > #
>
> > # To specify a different ordering, give the fully qualified name of a
>
> > String # Comparator. If the class can't be found, an error will be
>
> > logged and page # sorting will fall back to the default "natural"
>
> > ordering. You can specify # any String Comparator class here BUT be
>
> > careful of using case insensitive # comparators as JSPWiki page names
>
> > may be case sensitive.
>
> > # Example: jspwiki.pageNameComparator.class =
>
> > my.fully.qualified.comparator # # For convenience, we have provided a
>
> > few possibly useful comparators:
>
> > #
>
> > # HumanComparator understands numbers and sorts in a more human
>
> > friendly # order (English only).  Using HumanComparator, the pages
>
> > "Page1", "Page2", # "Page10" will sort in that order.
>
> > # Example: jspwiki.pageNameComparator.class = HumanComparator # #
>
> > LocaleComparator uses the server's Locale for ordering.  Useful if
>
> > your # content is always in a language other than English.  Does not
>
> > do human # friendly numeric ordering.
>
> > # Example: jspwiki.pageNameComparator.class = LocaleComparator #
>
> > #jspwiki.pageNameComparator.class =
>
> >
>
> > #
>
> > #  Set to true, if you want to cache page data into memory.  This is #
>
> > in general a good idea.
>
> > #
>
> > #  Default is false (no cache).
>
> > #
>
> > #  NB: This replaces the JSPWiki 1.x "CachingProvider" setting, since it
>
> > #      probably was too confusing.
>
> > #
>
> > jspwiki.usePageCache =true
>
> >
>
> > #
>
> > #  Determines where wiki files are kept for FileSystemProvider #  and
>
> > RCSFileProvider # #  If you're using Windows, then you must duplicate
>
> > the backslashes.
>
> > #  For example, use:
>
> > #
>
> > #  jspwiki.fileSystemProvider.pageDir = C:\\Data\\jspwiki #
>
> > jspwiki.fileSystemProvider.pageDir =/jspwiki/data
>
> >
>
> > #
>
> > #  The JSPWiki working directory.  If not set, a temporary path will #
>
> > be used.  You can see the location of the workdir in the logs.
>
> > #  It is HIGHLY recommended that you set this.
>
> > #
>
> > #  The working directory is used to cache things like Lucene search #
>
> > results.
>
> > #
>
> > #jspwiki.workDir =
>
> >
>
> > #
>
> > #  ATTACHMENTS:
>
> > #
>
> > #  Use the following property to define which attachment provider #
>
> > you want to use.  You have basically two choices:
>
> > #    * Set the value to BasicAttachmentProvider
>
> > #      a simple, flat file versioning provider
>
> > #    * Leave the value empty (or just comment the line out)
>
> > #      the attachment functionality is disabled
>
> > #
>
> > jspwiki.attachmentProvider =BasicAttachmentProvider
>
> >
>
> > #
>
> > #  The BasicAttachmentProvider needs to know where to store the files
>
> > #  the user has uploaded.  It's okay to put these in the same
>
> > directory #  as you put your text files (i.e. the pageDir setting above).
>
> > #
>
> > #  If you're using Windows, then you must duplicate the backslashes.
>
> > #  For example, use:
>
> > #
>
> > #  jspwiki.basicAttachmentProvider.storageDir = C:\\Data\\jspwiki #
>
> > jspwiki.basicAttachmentProvider.storageDir =/jspwiki/data
>
> >
>
> > #
>
> > #  You can tell the BasicAttachmentProvider to add a flag #  so that
>
> > browsers do not cache certain (or all) attachment #  types. This is
>
> > useful in intranet environments. You should activate #  this if your
>
> > users complain that their excel files are not uploaded #  correctly
>
> > and they still do have an old version: Usually the #  file was
>
> > uploaded correctly, but they get the locally cached version # #  You
>
> > can use regular expressions to disable the cache, e.g the #  following
>
> > example will disable browser cache for all excel and word files # #
>
> > If you don't define this property, cache is enabled by default for #
>
> > all attachments # #  jspwiki.basicAttachmentProvider.disableCache =
>
> > .*\.xls|.*\.doc
>
> >
>
> > #
>
> > #  You can limit the maximum size of an attachment by setting this #
>
> > value.  The value is in bytes, and by default all attachments #  are
>
> > accepted.
>
> > # This limit is not enforced for users with AdminPermissions.
>
> > #
>
> > #  The following line would limit the attachment size to 100,000 bytes
>
> > #jspwiki.attachment.maxsize=100000
>
> >
>
> > #
>
> > #  By default JSPWiki accepts all types of attachments.  However, you
>
> > #  can allow some types only, or forbid some other types.  By default,
>
> > #  all file types are allowed (if you do not specify the "allow" list
>
> > #  at all or it is empty).
>
> > # These allow/forbid statements are not enforced for users with
>
> > AdminPermissions.
>
> > #
>
> > #  These both are space-separated lists of file suffixes # #  Example:
>
> > Allow only PNG, JPG, ZIP and JAR file attachments
>
> > #jspwiki.attachment.allow=.png .jpg .zip .jar
>
> >
>
> > #  Example: Forbid HTML, PHP, ASP and EXE
>
> > #jspwiki.attachment.forbid=.html .htm .php .asp .exe
>
> >
>
> > #
>
> > #  page Diff Representation
>
> > #
>
> > #  To show differences between page versions, you can define a #
>
> > difference provider.
>
> > #  The following choices are available:
>
> > #    * TraditionalDiffProvider - Uses internal (java) diff
>
> > #        to create a list of changes and shows it line by
>
> > #        line colored. This is the default
>
> > #    * ContextualDiffProvider - Uses internal (java) diff
>
> > #        to create changes inline and shows it on a word by
>
> > #        word basis using CSS. This is much superior to the
>
> > #        traditional diff provider, however, it is still quite
>
> > #        new and not much tested. YMMV.
>
> > #    * ExternalDiffProvider - uses a system diff program (which
>
> > #        can be configured using "jspwiki.diffCommand") to
>
> > #        create an unified (!) diff.
>
> > #
>
> > #        Example for a diff command:
>
> > #        jspwiki.diffCommand = /usr/bin/diff -u %s1 %s2
>
> > #
>
> > jspwiki.diffProvider =TraditionalDiffProvider
>
> >
>
> > #  Determines if you need to have relative urls or not.  If the
>
> > baseURL #  is not set, then this has no effect, but if you set the
>
> > baseURL (which #  is highly recommended), you can use this to set
> relative urls.
>
> > #
>
> > #  Possible values are "absolute" and "relative".
>
> > #
>
> > #jspwiki.referenceStyle=relative
>
> >
>
> > #
>
> > #  Determines which character encoding JSPWiki should use.  If you
>
> > want #  to support all languages in your Wiki, you probably want to
>
> > enable #  this.  From JSPWiki 2.2, it is strongly suggested that you use
> UTF-8.
>
> > #
>
> > #  Note that you can't switch these in the mean time, since the way
>
> > the #  files are encoded on disk is incompatible between ISO-Latin1 and
> UTF-8.
>
> > #  Don't try.  You'll get all sorts of interesting problems, if you do.
>
> > #
>
> > #  Possible values are 'ISO-8859-1' (default, if none has been
>
> > specified) #  and 'UTF-8'.
>
> >
>
> > jspwiki.encoding =UTF-8
>
> >
>
> > #
>
> > #  Determines whether raw HTML is allowed as Wiki input.
>
> > #
>
> > #  THIS IS A DANGEROUS OPTION!
>
> > #
>
> > #  If you decide to allow raw HTML, understand that ANY person who has
>
> > #  access to your Wiki site can embed ANY sort of malicious
>
> > JavaScript, #  or plugin, or ActiveX, or whatever on your site.  They
>
> > can even mess it #  up so royally it is impossible for you to replace
>
> > the situation without #  the need of direct access to the repository.
>
> > So think twice before #  allowing raw HTML on your own site.
>
> > #
>
> > #  Most probably you want to use this on Intranets, or personal
>
> > servers, #  where only a handful of people can access the wiki.
>
> > #
>
> > #  Text between {{{ and }}} -options is not affected by this setting,
>
> > so #  it's always safe to quote HTML code with those.
>
> > #
>
> > #  The default for this option is "false".
>
> > #
>
> > jspwiki.translatorReader.allowHTML =false
>
> >
>
> >
>
> > ######################################################################
>
> > ######
>
> > #
>
> > #  Usability niceties.
>
> > #
>
> > #
>
> > #  If this property is set to "true", then page titles are rendered #
>
> > using an extra space between every capital letter.  It may make #
>
> > page titles readable on some occasions, but it does have the #
>
> > drawback of making the titles look a bit funny at times.
>
> > #
>
> > jspwiki.breakTitleWithSpaces =false
>
> >
>
> > #
>
> > #  If set to true, this property means that "WikiName" and "WikiNames"
>
> > #  are considered equal when linking between them.  Setting this to #
>
> > true does not prevent you from having both kinds of pages - we just #
>
> > fall back to the other one if the primary name does not exist.
>
> > #
>
> > #  For any other language, you'll probably want to turn this off.
>
> > #
>
> > jspwiki.translatorReader.matchEnglishPlurals =true
>
> >
>
> > #
>
> > #  If you set this to true, the Wiki translator will then also
>
> > consider #  "traditional" WikiNames (that is, names of pages
>
> > JustSmashedTogether #  without square brackets) as hyperlinks.  This
>
> > technique is also #  known as "CamelCase", or "BumpyCase", or
>
> > "InterCapping".  I personally #  like CamelCase as a word, which is
>
> > why this property is named as it is :-).
>
> > #
>
> > #  By default this is false, since traditional WikiLinks may confuse
>
> > newbies.
>
> > #
>
> > #  This option can be overridden on a per-page basis using the SET
>
> > directive.
>
> > #
>
> > jspwiki.translatorReader.camelCaseLinks =false
>
> >
>
> > #
>
> > #  This sets the default template used by the Wiki engine.  The
>
> > templates #  live in templates/<template name>.  JSPWiki will attempt
>
> > to find three #  basic templates from that directory: "ViewTemplate,"
> "EditTemplate"
>
> > #  and "AdminTemplate"
>
> > #
>
> > #  By default this is called "default".
>
> > #
>
> > #  This option can be overridden on a per-page basis using the SET
>
> > directive.
>
> > #
>
> > jspwiki.templateDir =default
>
> >
>
> >
>
> > #
>
> > #  The name of the front page.  This is the page that gets loaded if
>
> > no #  other page is loaded.  Up until JSPWiki 1.9.28, it was always
>
> > called #  "Main", but now you can easily change the default front page
>
> > here.  If not #  defined, uses "Main".
>
> > #
>
> > #jspwiki.frontPage = Main
>
> >
>
> > #
>
> > #  Allow creation of empty pages. Defaults to false.
>
> > #
>
> > #jspwiki.allowCreationOfEmptyPages = false
>
> >
>
> > #
>
> > #  If set to true, all outward links have a small icon attached.  The
>
> > icon #  can be found from images/out.png.  Default is true.
>
> > #
>
> > jspwiki.translatorReader.useOutlinkImage =true
>
> >
>
> > #
>
> > #  Set this to the number of minutes a person can "lock" a page #  for
>
> > while he is editing it.
>
> > #
>
> > jspwiki.lockExpiryTime =60
>
> >
>
> > #
>
> > #  Search provider used for searching pages and attachments.
>
> > #  Default is LuceneSearchProvider, but you can fall back to
>
> > BasicSearchProvider # jspwiki.searchProvider =LuceneSearchProvider
>
> >
>
> > #
>
> > #  If your wiki's language is something else than English, you might #
>
> > want to visit jakarta.apache.org/lucene and download a proper Analyzer
>
> > #  for your language.  Default is to use StandardAnalyzer.
>
> > #
>
> > #jspwiki.lucene.analyzer =
>
> > org.apache.lucene.analysis.standard.StandardAnalyzer
>
> >
>
> >
>
> > ######################################################################
>
> > ######
>
> > #
>
> > #  Special page references.
>
> > #
>
> > #  The URL is relative to Wiki.jsp.  However, if you use #  a full,
>
> > absolute URL, you can also do that.
>
> > #
>
> > # Example to redirect all requests to a page called 'OriginalWiki'
>
> > # to the original wikiwiki at http://c2.com/cgi/wiki # #
>
> > jspwiki.specialPage.OriginalWiki = http://c2.com/cgi/wiki # #  Note
>
> > that it is entirely possible to override any Wiki page, even #  an
>
> > existing one by redefining it here.
>
> > #
>
> > jspwiki.specialPage.CreateGroup =NewGroup.jsp
>
> > #jspwiki.specialPage.FindPage = Search.jsp jspwiki.specialPage.Search
>
> > =Search.jsp jspwiki.specialPage.Login =Login.jsp
>
> > jspwiki.specialPage.NewGroup =NewGroup.jsp
>
> > jspwiki.specialPage.UserPreferences =UserPreferences.jsp
>
> > jspwiki.specialPage.Workflow =Workflow.jsp
>
> >
>
> >
>
> > ######################################################################
>
> > #######
>
> > #
>
> > #  Plugin search paths.
>
> > #
>
> > #  Define here the packages you want to use for searching plugins, #
>
> > separated with commas.
>
> > #  For example, use the following command to add
>
> > "org.myorganisation.jspwiki.myplugins"
>
> > #  and "com.foobar.myplugins" to the search path.
>
> > #
>
> > #  jspwiki.plugin.searchPath =
>
> > org.myorganisation.jspwiki.myplugins,com.foobar.myplugins
>
> > #
>
> > #  The default path is "com.ecyrd.jspwiki.plugin", and it will be
>
> > always #  the last item on the path.  This allows you to override
>
> > JSPWiki default #  plugins.  Note that you are only adding to the
>
> > path, not replacing it (ie.
>
> > #  the default path is never removed.) # #  If the path is not
>
> > specified (and there is no jspwiki_module.xml with the #  plugin JAR),
>
> > you need to either declare the search path by hand, or #  use a fully
>
> > qualified name.
>
> > #
>
> > #  If you are a plugin developer, please consider deploying a
>
> > jspwiki_module.xml #  file with your plugin JAR, so that the user does
>
> > not have to set the searchPath.
>
> > #
>
> > #  jspwiki.plugin.searchPath =
>
> > org.myorganisation.jspwiki.myplugins,com.foobar.myplugins
>
> > #
>
> > jspwiki.plugin.searchPath =
>
> >
>
> >
>
> > ######################################################################
>
> > #######
>
> > #
>
> > #  Page filters
>
> > #
>
> > #  Normally, the filter configuration is in your WEB-INF/ directory,
>
> > so you #  do not need to go and specify this.  However, if your
>
> > filters.xml live somewhere #  else, you'll have to specify it here.
>
> > #
>
> > #jspwiki.filterConfig = /some/path/to/your/filters.xml
>
> >
>
> >
>
> > ######################################################################
>
> > #######
>
> > #
>
> > #  URL Constructor
>
> > #
>
> > #  JSPWiki by default generates page and attachment links that use JSP
>
> > #  pages and request parameters. It can also use alternative URL #
>
> > constructors so that URL pages resemble traditional website paths, too.
>
> > #  You have three choices for generating URLs:
>
> > #
>
> > #     DefaultURLConstructor - uses JSPs for all references:
>
> > #         http://mywiki.com/jspwiki/Wiki.jsp?page=Main
>
> > #         http://mywiki.com/jspwiki/Edit.jsp?page=Main
>
> > #
>
> > #     ShortURLConstructor - uses path-like reference style:
>
> > #         http://mywiki.com/jspwiki/wiki/Main
>
> > #         http://mywiki.com/jspwiki/wiki/Main?do=Edit
>
> > #
>
> > #     ShortViewURLConstructor - uses path-like references for views; JSPs
>
> > for everything else:
>
> > #         http://mywiki.com/jspwiki/wiki/Main
>
> > #         http://mywiki.com/jspwiki/Edit.jsp?page=Main
>
> > #
>
> > #  Of course, you can also write your own implementation if you wish.
>
> > #
>
> > #  For either of the ShortURL constructors, you can also specify a #
>
> > prefix path to go in front of page names. By default, the #  prefix is
>
> > 'wiki/'.
>
> > #
>
> > #  Be warned that the ShortURLConstructor does not work well with any
>
> > other editor #  except the built-in plaintext one.  Use
>
> > ShortViewURLConstructor if you plan #  to enable any other ones.
>
> > #
>
> > #jspwiki.urlConstructor = DefaultURLConstructor
>
> > #jspwiki.urlConstructor = ShortViewURLConstructor
>
> > #jspwiki.shortURLConstructor.prefix = wiki/
>
> >
>
> >
>
> > ######################################################################
>
> > #######
>
> > #
>
> > # Rendering
>
> > #
>
> > # At this time, entries here are strictly for development and testing.
>
> > #
>
> >
>
> > # Disable internal caching of pre-constructed document DOMs.
>
> > # This may be necessary if you require custom rendering that must not
>
> > be cached.
>
> > #jspwiki.renderingManager.useCache = false
>
> >
>
> >
>
> >
>
> > ######################################################################
>
> > #######
>
> > #
>
> > #  Security, authentication and authorization #
>
> >
>
> > #  JSPWiki supports a plugin-based interface for talking to different
>
> > #  kinds of authentication and authorization systems. By
> "authentication,"
>
> > #  we mean a system for logging in a user to establish their identity.
>
> > #  By "authorization," we mean a system for figuring out what actions
>
> > #  users can perform based on their authenticated identities.
>
> > #
>
> > #  For users looking to get started quickly, the default settings
>
> > below #  should work fine. In addition to the properties below, you
>
> > may also #  want to modify the security policy file
>
> > WEB-INF/jspwiki.policy. See #  the policy file for more details.
>
> > #
>
> > #  AUTHENTICATION
>
> > #
>
> > #  For authentication, JSPWiki uses JAAS (Java Authentication and
>
> > Authorization #  Service) in combination with a servlet filter that
>
> > picks up any credentials #  set by the servlet container. The
>
> > Authentication system is configured below.
>
> > #
>
> > #  You must choose either (A) Container or (B) Custom authentication.
>
> > (B) is the default.
>
> > #
>
> > #  A) CONTAINER AUTHENTICATION
>
> > #  JSPWiki will always (passively) collect credentials supplied by
>
> > your servlet #  container, via
>
> > HttpServletRequest.getUserPrincipal/getRemote user. You do not #  need
>
> > to do anything to enable this. In addition, you can cause JSPWiki
>
> > users #  to log in to the web container by uncommenting the the
>
> > <security-constraint> #  elements in WEB-INF/web.xml.
>
> > #
>
> > #  B) CUSTOM AUTHENTICATION
>
> > #  If you do not wish to use container-managed authentication, you can
>
> > use JSPWiki's #  own custom authentication system. This uses a JAAS
>
> > LoginModule (supplied
>
> > below)
>
> > #  to log in the user. You can use any JAAS LoginModule you want.
>
> > #  The default class is
>
> > com.ecyrd.jspwiki.auth.login.UserDatabaseLoginModule,
>
> > #  which compares the supplied username and hashed password with the
>
> > values stored #  in the configured UserDatabase (see USER DATABASE
>
> > below).
>
> > #
>
> > #  Supply the JAAS LoginModule class used for custom authentication here.
>
> > #  The implementation MUST have a zero-argument constructor (as noted
>
> > in the #  javax.security.auth.spi.LoginModule Javadocs).
>
> > jspwiki.loginModule.class
>
> > =com.ecyrd.jspwiki.auth.login.UserDatabaseLoginModule
>
> >
>
> > #
>
> > # JAAS LoginContext parameters used to initialize the LoginModule.
>
> > Note that 'param1'
>
> > #  etc. should be replaced with the actual parameter names. The
>
> > parameter names and # values will be loaded to a Map and passed to the
>
> > LoginModule as the 'options' parameter # when its initialize() method
>
> > is called. The default UserDatabaseLoginModule class does # not need
>
> > any options.
>
> > #jspwiki.loginModule.options.param1 = value1
>
> > #jspwiki.loginModule.options.param2 = value2
>
> >
>
> > #
>
> > #  Cookie authentication & assertion
>
> > #
>
> > #  If this value is set to "true", then JSPWiki will allow you to
> "assert"
>
> > an
>
> > #  identity using a cookie.  It's still considered to be unsafe, just
>
> > like no #  login at all, but it is useful when you have no need to
>
> > force everyone to login.
>
> > #
>
> > #  By default, this is on.
>
> > #
>
> > #jspwiki.cookieAssertions=true
>
> >
>
> > #
>
> > #  If you would like to keep your users logged in for weeks at a time,
>
> > you can #  turn on "cookie authentication" feature.  However, this
>
> > comes with important #  security caveats:
>
> > #  1) User will stay logged in into your system for weeks.  This means
>
> > that if
>
> > #     someone manages to nab the cookie during this time, they can
> pretend
>
> > to
>
> > #     be that user.
>
> > #  2) The mappings between cookies and users are written in your
>
> > filesystem,
>
> > #     in $jspwiki.workDir/logincookies.  Access to this directory means
>
> > that
>
> > #     the ability to fake anyone in the wiki, so please make sure that
> only
>
> > #     the proper admin has read access to this directory.
>
> > #
>
> > #  By default, cookie authentication is off.
>
> > #
>
> > #jspwiki.cookieAuthentication=false
>
> >
>
> > #
>
> > #  Defines how many days the cookies are kept, and how often the
>
> > people have to log in.
>
> > #  The default is two weeks, i.e. 14 days.  If you need a shorter
>
> > period than one day, #  turn off cookie authentication, then tweak
>
> > your web.xml to allow for longer sessions.
>
> > #
>
> > #jspwiki.cookieAuthentication.expiry=14
>
> >
>
> > #
>
> > #
>
> > #  AUTHORIZATION
>
> > #
>
> > #  For authorization, JSPWiki has a two-tier system. When we want to #
>
> > determine whether a user has permission to perform a certain action, #
>
> > we first consult (A) an external "authorizer" to determine if the user
>
> > #  is a member of the required role. In addition to checking its
>
> > external #  authorizer, it also checks (B) its GroupManager for
> wiki-managed groups.
>
> > #
>
> > #  A) EXTERNAL AUTHORIZATION
>
> > #  By default, JSPWiki uses the servlet container's authorization
>
> > service #  for to check what roles the user belongs to (that is, it
>
> > calls #  HttpServletRequest.isUserInRole(String)). After the user
>
> > authenticates, #  the default Authorizer (WebContainerAuthorizer)
>
> > checks to see if the user #  belongs to the roles listed in web.xml
>
> > using <security-role>/<role-name> or #  <auth-constraint>/<role-name>
>
> > elements. However, you can use another #  Authorizer if you wish;
>
> > specify that class here.
>
> >
>
> > jspwiki.authorizer
>
> > =com.ecyrd.jspwiki.auth.authorize.WebContainerAuthorizer
>
> >
>
> > #  B) GROUPS
>
> > #  As an additional source of authorization, users can belong to
>
> > discretionary #  "wiki groups" that the users manage themselves. Wiki
>
> > groups are stored in a #  GroupDatabase. The default group database
>
> > uses an XML file for persistent #  storage. Override with your own
>
> > GroupDatabase implementation with this
>
> > property:
>
> >
>
> > jspwiki.groupdatabase
>
> > =com.ecyrd.jspwiki.auth.authorize.XMLGroupDatabase
>
> >
>
> > #  The default group database implementation stores member lists #  in
>
> > an XML file. The location of this file should be in a secure directory
>
> > #  in the filesystem; for example, in /etc or your servlet container's
>
> > #  configuration directory If you do not supply a value for this
>
> > property, #  a blank group database will be initialized in the
>
> > WEB-INF/ directory of the #  deployed webapp. Since these directories
>
> > are often overwritten when webapps #  are undeployed or redeployed,
>
> > you should probably set this property to #  something useful as soon
>
> > as you can. But for test wikis, it's probably #  ok to leave this
>
> > un-set, as long as users know that their groups could #  "disappear"
>
> > if the wiki app is ever redeployed.
>
> >
>
> > #jspwiki.xmlGroupDatabaseFile = /etc/tomcat/groupdatabase.xml
>
> >
>
> > #  USER DATABASE
>
> > #  User's wiki profiles are stored in a UserDatabase. The default user
>
> > database #  uses an XML file for persistent storage.
>
> > #  Override with your own UserDatabase implementation with this property:
>
> >
>
> > jspwiki.userdatabase =com.ecyrd.jspwiki.auth.user.XMLUserDatabase
>
> >
>
> > #  The default user database implementation stores usernames and
>
> > passwords #  in an XML file. Passwords are SHA-1 hashed. The location
>
> > of this file #  should be in a secure directory in the filesystem; for
>
> > example, in #  /etc or your servlet container's configuration directory.
>
> > #  If you do not supply a value for this property, a blank user
>
> > database #  will be initialized in the WEB-INF/ directory of the deployed
> webapp.
>
> > #  Since these directories are often overwritten when webapps are #
>
> > undeployed or redeployed, you should probably set this property to #
>
> > something useful as soon as you can. But for test wikis, it's probably
>
> > #  ok to leave this un-set, as long as users know that their profiles
>
> > could #  "disappear" if the wiki app is ever redeployed.
>
> >
>
> > #jspwiki.xmlUserDatabaseFile = /etc/tomcat/userdatabase.xml
>
> >
>
> > # You can also use a JDBC database for storing user profiles.
>
> > # See the online AuthenticationAndAuthorization2.3 docs for details on
>
> > # how to configure it.
>
> >
>
> > #jspwiki.userdatabase = com.ecyrd.jspwiki.auth.user.JDBCUserDatabase
>
> >
>
> > #  If your JSPWiki user database shares login information with your #
>
> > web container's authentication realm, you can configure JSPWiki to #
>
> > add container users. At present, this only works with
>
> > JDBCUserDatabase, #  and only if you've configured your web container
>
> > to use a database #  with compatible columns and tables. If you don't
>
> > know what this means, #  then leave this property set to FALSE (the
> default).
>
> >
>
> > #jspwiki.userdatabase.isSharedWithContainer = false
>
> >
>
> > #  ACCESS CONTROL LISTS
>
> > #  Last but not least, JSPWiki needs a way of reading and persisting
>
> > page #  access control lists. The default implementation reads these
>
> > from the page #  markup. For example: "[{ALLOW edit Charlie}]". If
>
> > using a custom #  ACL manager, specify the AclManager implementation
>
> > class here:
>
> >
>
> > jspwiki.aclManager =com.ecyrd.jspwiki.auth.acl.DefaultAclManager
>
> >
>
> >
>
> > ######################################################################
>
> > #######
>
> > #
>
> > # InterWiki links
>
> > #
>
> > # The %s is replaced with the page reference (specify # multiple times
>
> > to get multiple references).  Page references should # appear in
>
> > format : [wiki:wikipage].
>
> > #
>
> > # This is the JSPWiki home.  In future, JSPWiki will probably rely on
>
> > this # for error messages, so I don't recommend that you change it.
>
> > jspwiki.interWikiRef.JSPWiki =http://www.jspwiki.org/wiki/%s
>
> >
>
> > # Here's how you can have directly links to the JSPWiki editor.
>
> > # Now you can put a hyperlink for editing "MainPage" by making # a
>
> > link [Edit:MainPage].
>
> > jspwiki.interWikiRef.Edit =Edit.jsp?page=%s
>
> >
>
> > #  This is the original WikiWikiWeb
>
> > jspwiki.interWikiRef.WikiWikiWeb =http://c2.com/cgi/wiki?%s
>
> >
>
> > #  TWiki, a very nice WikiClone.
>
> > jspwiki.interWikiRef.TWiki =http://twiki.org/cgi-bin/view/TWiki/%s
>
> >
>
> > #  MeatballWiki, which seems to be quite popular.
>
> > jspwiki.interWikiRef.MeatballWiki =http://usemod.com/cgi-bin/mb.pl?%s
>
> >
>
> > #  Wikipedia, a Wiki encyclopedia!
>
> > jspwiki.interWikiRef.Wikipedia =http://www.wikipedia.com/wiki/%s
>
> >
>
> > #  Google, the ubiquitous search engine.
>
> > jspwiki.interWikiRef.Google =http://www.google.com/search?q=%s
>
> >
>
> > #  JSPWiki documentation (for this release) jspwiki.interWikiRef.Doc
>
> > =http://doc.jspwiki.org/2.8/wiki/%s
>
> >
>
> >
>
> > ######################################################################
>
> > ######
>
> > #
>
> > # Define which image types are inlined.
>
> > # These are your standard glob expressions (just like in your #
>
> > Windows or UNIX shells).  Default pattern is to include all PNG #
>
> > images.  If you specify something here, you will override the default.
>
> > #
>
> > # Don't forget to increase the number after the dot - duplicate
>
> > entries # cause problems!
>
> > #
>
> > # For example:
>
> > #   Inline all JPG files, PNG files and all files from images.com:
>
> > #
>
> > #      jspwiki.translatorReader.inlinePattern.1 = *.jpg
>
> > #      jspwiki.translatorReader.inlinePattern.2 = *.png
>
> > #      jspwiki.translatorReader.inlinePattern.3 = http://images.com/*
>
> >
>
> >
>
> > ######################################################################
>
> > #####
>
> > #
>
> > #  Determine how the RSS (Rich Site Summary) file generation should work.
>
> > #  RSS is a standard pioneered by Netscape, which allows you to join
>
> > your #  Wiki with a huge number of different news services around the
> world.
>
> > #  Try a Google search on RSS and see what you can do with it.
>
> > #
>
> > #  All of these settings were added in JSPWiki 1.7.6.
>
> > #
>
> > #  Note that jspwiki.baseURL MUST BE DEFINED if you want to enable RSS!
>
> > #
>
> > #  Determine if the RSS file should be generated at all.  Allowed
>
> > values #  are "true" and "false".  Default is "false".
>
> > #
>
> > jspwiki.rss.generate =false
>
> >
>
> > #
>
> > #  Determine the name of the RSS file. This path is relative to your #
>
> > Wiki root.  Default is "rss.rdf"
>
> > #
>
> > jspwiki.rss.fileName =rss.rdf
>
> >
>
> > #
>
> > #  Determine the refresh interval (ie. how often the RSS file is
>
> > regenerated.
>
> > #  It is not recommended to make this too often, or you'll choke your
>
> > server.
>
> > #  Anything above five minutes is probably okay.  The default value is
>
> > one hour.
>
> > #  The value should be in seconds.
>
> > #
>
> > jspwiki.rss.interval =3600
>
> >
>
> > #
>
> > #  The text you want to be shown as your "channel description" when
>
> > someone #  subscribes to it.  You can be quite verbose here, up to 500
>
> > characters or #  so.  You can continue to a new line by adding a
>
> > backslash to the end of the #  line.  Default is to have no
>
> > description.
>
> > #
>
> > jspwiki.rss.channelDescription =Oh poor me, my owner has not set a
>
> > channel description at all. Pity me.
>
> >                                 a channel description at all. \
>
> >                                 Pity me.
>
> >
>
> > #
>
> > #  The language of your Wiki.  This is a standard, two-letter language
>
> > #  code, or in case of some languages, two letters for the country, #
>
> > a dash, and two letters for the dialect.
>
> > #
>
> > jspwiki.rss.channelLanguage =en-us
>
> >
>
> > ######################################################################
>
> > #####
>
> > #
>
> > #  JDBC Configuration. Tells JSPWiki which tables and columns to map #
>
> > to for the JDBCUserDatabase and JDBCGroupDatabase. For more info, see
>
> > the #  JavaDoc for classes
>
> > com.ecyrd.jspwiki.auth.user.JDBCUserDatabase and #
>
> > com.ecyrd.jspwiki.auth.authorize.JDBCGroupDatabase.
>
> > #
>
> > jspwiki.userdatabase.datasource=jdbc/UserDatabase
>
> > jspwiki.userdatabase.table=users
>
> > jspwiki.userdatabase.uid=uid
>
> > jspwiki.userdatabase.email=email
>
> > jspwiki.userdatabase.fullName=full_name
>
> > jspwiki.userdatabase.loginName=login_name
>
> > jspwiki.userdatabase.password=password
>
> > jspwiki.userdatabase.wikiName=wiki_name
>
> > jspwiki.userdatabase.created=created
>
> > jspwiki.userdatabase.modified=modified
>
> > jspwiki.userdatabase.lockExpiry=lock_expiry
>
> > jspwiki.userdatabase.attributes=attributes
>
> > jspwiki.userdatabase.roleTable=role
>
> > jspwiki.userdatabase.role=role
>
> > jspwiki.groupdatabase.datasource=jdbc/GroupDatabase
>
> > jspwiki.groupdatabase.table=groups
>
> > jspwiki.groupdatabase.membertable=member
>
> > jspwiki.groupdatabase.created=created
>
> > jspwiki.groupdatabase.creator=creator
>
> > jspwiki.groupdatabase.name=name
>
> > jspwiki.groupdatabase.member=member
>
> > jspwiki.groupdatabase.modified=modified
>
> > jspwiki.groupdatabase.modifier=modifier
>
> >
>
> > ######################################################################
>
> > #####
>
> > #
>
> > #  JavaMail configuration. If you wish to allow your users to recover
>
> > #  their passwords via email, you should configure these properties.
>
> > #  JavaMail can use either a container-managed JNDI resource factory #
>
> > (recommended, and the default), or a stand-alone factory whose
>
> > properties #  are configured with mail.* properties in this file
>
> > (below).
>
> > #
>
> >
>
> > #  A. Configure the address from which the email appears to come.
>
> > #     If you're going to use a mail session obtained via JNDI, this
> setting
>
> > #     will only be used if it hasn't already been configured in the
>
> > obtained
>
> > #     session itself. If you comment it out, JSPWiki will use its
> internal
>
> > #     default value.
>
> > #     If you're going to use a stand-alone mail session, you will surely
>
> > want
>
> > #     to configure it, otherwise the internal default value will be used.
>
> > #
>
> > mail.from =@mail.from@<mailto:=@mail.from@>
>
> >
>
> > #  B. JNDI Resource Factory Configuration. JSPWiki will try this first.
>
> > #     You will need to configure your container to provide a JavaMail
>
> > #     resource factory. See your container documentation, or check our
>
> > #     fairly complete documentation (with examples for Tomcat) in
>
> > #     the JavaDocs for com.ecyrd.jspwiki.util.MailUtil.
>
> > #
>
> > #  JNDI resource name. The commented-out value is the default.
>
> > #jspwiki.mail.jndiname = mail/Session
>
> >
>
> > #  C. Stand-alone Resource Factory. JSPWiki will use these values if
>
> > JNDI fails.
>
> > #
>
> > #  Your SMTP host (i.e. the one which sends email) mail.smtp.host
>
> > =@mail.smtp.host@<mailto:=@mail.smtp.host@>
>
> >
>
> > # If for some reason the standard smtp port (25) is blocked, you can
>
> > change it here #mail.smtp.port = @mail.smtp.port@
>
> >
>
> > # If you are using a webserver that is publically accessible it
>
> > usually # doesn't allow you to send mail anonymously # (because then
>
> > this mailserver would become an open relay).
>
> > # Therefore you can indicate your account information here...
>
> > #
>
> > #mail.smtp.account = @mail.smtp.account@ #mail.smtp.password =
>
> > @mail.smtp.password@
>
> >
>
> > # The properties below control connection timeouts and TLS
>
> > (encryption) # if the mailserver supports it. The commented-out values
> are the defaults.
>
> > #mail.smtp.timeout = 5000
>
> > #mail.smtp.connectiontimeout = 5000
>
> > #mail.smtp.starttls.enable = true
>
> >
>
> > ######################################################################
>
> > #####
>
> > #
>
> > #  Configure logs.  See log4j documentation for more information #  on
>
> > how you can configure the logs.
>
> > #
>
> > #  Log4j is available at http://jakarta.apache.org/log4j # #  WARNING
>
> > WARNING WILL ROBINSON: If you turn on DEBUG logging, be aware #  that
>
> > some security-sensitive information will be logged (such as session
>
> > IDs).
>
> > #  Please be careful.
>
> > #
>
> > #  Send mail to root on all problems containing warnings.
>
> > #
>
> > #log4j.appender.mail = org.apache.log4j.net.SMTPAppender
>
> > #log4j.appender.mail.Threshold = WARN #log4j.appender.mail.To =
>
> > root@localhost #log4j.appender.mail.From = JSPWiki@localhost
>
> > #log4j.appender.mail.Subject = Problem with JSPWiki!
>
> > #log4j.appender.mail.SMTPHost = mail
>
> >
>
> > #log4j.appender.mail.layout = org.apache.log4j.PatternLayout
>
> > #log4j.appender.mail.layout.ConversionPattern =%d [%t] %p %c %x - %m%n
>
> >
>
> > #
>
> > #  Log everything into a file, roll it over every 10 MB, keep #  only
>
> > 14 latest ones.
>
> > #
>
> > log4j.appender.FileLog =org.apache.log4j.RollingFileAppender
>
> > log4j.appender.FileLog.MaxFileSize    =10MB
>
> > log4j.appender.FileLog.MaxBackupIndex =14 log4j.appender.FileLog.File
>
> > =/jspwiki/tmp/jspwiki.log log4j.appender.FileLog.layout
>
> > =org.apache.log4j.PatternLayout
>
> > log4j.appender.FileLog.layout.ConversionPattern=%d [%t] %p %c %x -
>
> > %m%n
>
> >
>
> > #
>
> > # If you want to use some other logging system (such as JBoss, which
>
> > uses # log4j already, comment this line out.  If you just don't want
>
> > any logs # at all, you can set it to be empty.  However, I suggest
>
> > that you do # at least to a level of WARN.
>
> > #
>
> > log4j.rootCategory=INFO,FileLog
>
> >
>
> > # Enable if you're using mailing, above.
>
> > #log4j.rootCategory=INFO,FileLog,mail
>
> >
>
> > #
>
> > # Uncomment these lines if you want to see detailed security event
> logging.
>
> > # The logging levels are as follows:
>
> > #  ERROR: login errors (other than failed/expired logins) #  WARN:
>
> > access denied, failed login (account expired, password/credential
>
> > expired)
>
> > #  INFO:  login, logout
>
> > #  DEBUG: add/remove group, add/remove group member, clear
>
> > groups/group members, access allowed # #log4j.logger.SecurityLog=INFO,
>
> > SecurityAppender #log4j.appender.SecurityAppender =
>
> > org.apache.log4j.RollingFileAppender
>
> > #log4j.appender.SecurityAppender.MaxFileSize    = 10MB
>
> > #log4j.appender.SecurityAppender.MaxBackupIndex = 14
>
> > #log4j.appender.SecurityAppender.File = @securitylog@
>
> > #log4j.appender.SecurityAppender.layout =
>
> > org.apache.log4j.PatternLayout
>
> > #log4j.appender.SecurityAppender.layout.ConversionPattern=%d %p - %m%n
>
> >
>
> > #
>
> > #  Uncomment these lines if you wish to receive detailed spam #
>
> > filter logging.
>
> > #
>
> > #log4j.logger.SpamLog=INFO,SpamAppender
>
> > #log4j.appender.SpamAppender = org.apache.log4j.RollingFileAppender
>
> > #log4j.appender.SpamAppender.MaxFileSize = 10MB
>
> > #log4j.appender.SpamAppender.MaxBackupIndex = 14
>
> > #log4j.appender.SpamAppender.File = @spamlog@
>
> > #log4j.appender.SpamAppender.layout = org.apache.log4j.PatternLayout
>
> > #log4j.appender.SpamAppender.layout.ConversionPattern=%d{ISO8601} %m%n
>
> >
>
> > ######################################################################
>
> > #####
>
> > #
>
> > # Workflow configuration
>
> > #
>
> > # The following properties map specific workflow steps to their
>
> > associated approvers # The name of the workflow or decision is the
>
> > part of the key after "jspwiki.approver.".
>
> > # This is a logical name JSPWiki uses to determine which Principal to
>
> > consult for approval.
>
> > # The Principal is identified up by AuthorizationManager at runtime;
>
> > it looks for a Principal # match as follows: GroupPrincipals; Roles;
>
> > WikiPrincipals/other principals. Thus, if a value # of "Admin" is
>
> > supplied JSPWiki will first check the GroupManager to see if group
>
> > Admin exits; # then the container roles, if any; then, user
>
> > Principals. If the value is blank or the # property is commented out,
>
> > it means that the workflow does not require approval.
>
> > #
>
> > # EXAMPLE:
>
> > # Uncomment the next line to require the Admin group (or Admin user,
>
> > if a group is not found) # to approve wiki pages after saving.
>
> > #jspwiki.approver.workflow.saveWikiPage=Admin
>
> >
>
> > # Uncomment the next line to require the Admin group to approve new
>
> > user profiles #jspwiki.approver.workflow.createUserProfile=Admin
>
> >
>
> > ### End of configuration file.
>
> >
>
> > jspwiki.workDir =/jspwiki/tmp/
>
> >
>
> > jspwiki.security = jaas
>
> >
>
> >
>
> > ________________________________
>
> >
>
> > This e-mail may contain Sprint Nextel proprietary information intended
>
> > for the sole use of the recipient(s). Any use by others is prohibited.
>
> > If you are not the intended recipient, please contact the sender and
>
> > delete all copies of the message.
>
> >
>
> ________________________________
>
> This e-mail may contain Sprint Nextel proprietary information intended for
> the sole use of the recipient(s). Any use by others is prohibited. If you
> are not the intended recipient, please contact the sender and delete all
> copies of the message.
>

________________________________

This e-mail may contain Sprint Nextel proprietary information intended for the sole use of the recipient(s). Any use by others is prohibited. If you are not the intended recipient, please contact the sender and delete all copies of the message.
Mime
View raw message