All this commotion got the best of me, so I gave it a spin. Plus I'm
running 2.4 and I probably should really upgrade.
At any rate, seemed to work for me, here's what I did:
1. Spun up a new Ubuntu Server 10.10 X64 VM
2. Created install folder /app
3. Downloaded JDK 1.6.0_24 X64 from Oracle
4. Installed Java into /app/jdk1.6.0_24
5. export JAVA_HOME=/app/jdk1.6.0_24
6. Downloaded Tomcat 6.0.32
7. Installed Tomcat in /app/web/apache-tomcat-6.0.32
8. Started up Tomcat to make sure its working. It was. Shut it down.
9. Downloaded JSPWiki 2.8.4
10. Installed JSPWiki into /app/web/sites/default/webapps/wiki
11. Installed corepages into /app/web/sites/default/webapps/wiki
12. Edited jspwiki.properties to fix paths for pageDir and storageDir
13. Created Tomcat webapp descriptor in
/app/web/apache-tomcat-6.0.32/conf/Catalina/localhost/wiki.xml
(attached)
14. Started up Tomcat hit the /wiki/Installer.jsp page in browser.
15. Restarted Tomcat. Verified I could create files as anonymous, and
I could login to admin account.
16. Changed WEB-INF/jspwiki.policy (attached) file so that only logged
in users can create/modify pages.
17. Restarted Tomcat. Verified I could not created/modify pages until
I logged in.
Seemed pretty straight forward to me. Much easier than getting JSPWiki
2.4 with a custom jspwiki.policy to work with Sun Java System Web Server
7.0.
:-)
The Security Configuration Verifier showed the exact permissions of
what I could do.
--joe
On 3/31/2011 6:28 AM, George, Kenneth V [NTK] wrote:
...AND...on my test machine (local) I am using 1.6.0_24
C:\Documents and Settings\kvg6037>java -version
java version "1.6.0_24"
Java(TM) SE Runtime Environment (build 1.6.0_24-b07)
Java HotSpot(TM) Client VM (build 19.1-b02, mixed mode, sharing)
-----Original Message-----
From: Janne Jalkanen [mailto:[email protected]]
Sent: Thursday, March 31, 2011 1:42 AM
To:[email protected]
Subject: Re: Profile Security NOT WORKING!!!
This is odd, since I'm running on same JSPWiki, Ubuntu 10.04, Tomcat 6.0.32
(which is BTW a recommended upgrade; Chrome 10 breaks on occasion otherwise),
and I have jspwiki.policy working. However, I am running OpenJDK
6b20-1.9.7-0ubuntu1~10.04.1.
Is it possible that for some reason Sun JDK's built-in policy management is
kicking in here? Or that it might just be broken in some odd fashion. Can you
try OpenJDK and see if that works for you?
/Janne
// $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 "*:*",
"modify";
// permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*",
"createPages";
};
// 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.
grant principal com.ecyrd.jspwiki.auth.authorize.Role "Asserted" {
// permission com.ecyrd.jspwiki.auth.permissions.PagePermission "*:*",
"modify";
// permission com.ecyrd.jspwiki.auth.permissions.WikiPermission "*",
"createPages";
permission com.ecyrd.jspwiki.auth.permissions.GroupPermission "*:*", "view";
};
// 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 "*";
};
<?xml version="1.0" encoding="UTF-8"?>
<Context path="/wiki" docBase="/app/web/sites/default/webapps/wiki" debug="0" reloadable="false">
<Valve className="org.apache.catalina.authenticator.NonLoginAuthenticator"
disableProxyCaching="true" securePagesWithPragma="false" />
<Resource name="mail/Session"
auth="Container"
type="javax.mail.Session"
mail.smtp.host="smtp.gmail.com"
mail.smtp.port="465"
mail.smtp.auth="true"
mail.smtp.user="[email protected]"
password="c0Npu3nce"
mail.smtp.starttls.enable="true"
mail.smtp.socketFactory.class="javax.net.ssl.SSLSocketFactory"
/>
</Context>
