incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harry Metske <harry.met...@gmail.com>
Subject Re: Profile Security NOT WORKING!!!
Date Mon, 28 Mar 2011 20:14:17 GMT
everything green doesn't look good to me, as an example :
http://www.computerhok.nl/tmp/JSPWiki%20Security%20Configuration%20Verifier.html
that's
how my local test JSPWiki looks like which is running an unmodified
jspwiki.policy.
You can hover the mouse over the red/green to see the details...

regards,
Harry

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

> 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
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message