incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Carlson, Eric R" <eric.carl...@kroger.com>
Subject RE: ALLOW tag not working properly
Date Mon, 23 Feb 2009 19:44:25 GMT
Janne,

        Here's the complete text of jspwiki.policy :

-------------------------------------------------

// $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";
// };

grant principal com.ecyrd.jspwiki.auth.authorize.Role "Anonymous" {
};


// 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";
// };

grant principal com.ecyrd.jspwiki.auth.authorize.Role "Asserted" {
};


// 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";
// };

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 "*";
};

----------------------------------------------

                                                Eric R. Carlson
                                                        Eric.Carlson@kroger.com

-----Original Message-----
From: Janne Jalkanen [mailto:Janne.Jalkanen@ecyrd.com]
Sent: Tuesday, February 17, 2009 3:00 PM
To: jspwiki-user@incubator.apache.org
Subject: Re: ALLOW tag not working properly


Well, this seems correct.  By default, both *should* have rename
authority, but delete is available to admins.

Did you change jspwiki.policy?  If so, can you show the modifications?

/Janne

On Feb 16, 2009, at 15:53 , Carlson, Eric R wrote:

> Janne,
>
>        One of the two users is an Admin, but the other isn't.
>
>        I logged on as both users, and clicked on the 'Info' tab for
> the page.   Both users have the authority to rename the page, but
> only one of the two has the button to delete the page.
>
>        I can send you my security directives from the jspwiki.policy
> if you'd like.
>
>                                                Eric R. Carlson
>                                                        Eric.Carlson@kroger.com
>
> -----Original Message-----
> From: Janne Jalkanen [mailto:Janne.Jalkanen@ecyrd.com]
> Sent: Thursday, February 12, 2009 4:05 PM
> To: jspwiki-user@incubator.apache.org
> Subject: Re: ALLOW tag not working properly
>
>
> Is it possible that you've accidentally given everyone admin rights
> (or wide-spread editing rights) in jspwiki.policy?
>
> /Janne
>
> On Feb 12, 2009, at 21:47 , Carlson, Eric R wrote:
>
>> One of the two users is an administrator.  I've done the test
>> where the admin created the page, marked it allowed only
>> for that user-id, but the non-admin was able to see and edit the
>> page.
>>
>>                               Eric R. Carlson
>>                                       Eric.Carlson@kroger.com
>>
>>
>> -----Original Message-----
>> From: Harry Metske [mailto:harry.metske@gmail.com]
>> Sent: Thursday, February 12, 2009 2:35 PM
>> To: jspwiki-user@incubator.apache.org
>> Subject: Re: ALLOW tag not working properly
>>
>> Did you already check if UserA is a JSPWiki administrator ?
>> Login, Select "My Prefs" and then the profile tab.
>>
>> And BTW, JSPWiki uses implied permissions, so you don't have to code
>> both
>> ALLOW's, ALLOW edit implies ALLOW view.
>>
>> Harry
>>
>>
>> 2009/2/12 Carlson, Eric R <eric.carlson@kroger.com>
>>
>>> OK, I turned on the Debug option, reran my scenario, and it still
>>> doesn't seem to be working.   Maybe I'm doing something wrong.
>>>
>>> Here's what I do.   I have two different user-ids for the wiki, say
>>> UserA and UserB.   I log on as UserA, create and edit a page that I
>>> call 'Allow Test Page'.   Allow Test Page consists of :
>>>
>>> [{ALLOW view UserB}]
>>> [{ALLOW edit UserB}]
>>>
>>> This is a page that only UserB should be able to see or edit.
>>>
>>> Now I save the changes to the page.  I next go into 'Recent
>>> Changes' to see the page name there.  I click on it (while
>>> logged on as UserA.  It lets me into the page just fine.  In
>>> fact, I can edit it and save it as well.
>>>
>>> The ALLOW tags don't seem to be having any effect at all.
>>> The messages in the log that come from the DEBUG option
>>> just indicate that UserA has Edited and Saved the page,
>>> along with a couple of lines about create a new Favorites page
>>> for UserA.
>>>
>>> Am I doing something wrong here?   I've also run the scenario
>>> where I log on as UserA, create and edit the page allowing only
>>> UserA to view or edit it, then logged on separately as UserB, and
>>> I can still see the page in the Recent Changes list, edit and save
>>> it.
>>>
>>>                      Eric R. Carlson
>>>                              Eric.Carlson@kroger.com
>>>
>>>
>>> -----Original Message-----
>>> From: Harry Metske [mailto:harry.metske@gmail.com]
>>> Sent: Thursday, February 12, 2009 12:09 PM
>>> To: jspwiki-user@incubator.apache.org
>>> Subject: Re: ALLOW tag not working properly
>>>
>>> well, that is completely correct.
>>> So, if you think SecurityConfig.jsp does not reveal any misconfig or
>>> something like that, I would start with the second step, which is
>>> turning
>>> on
>>> debug, and see what the security.log says.
>>>
>>> Harry
>>>
>>>
>>> 2009/2/12 Carlson, Eric R <eric.carlson@kroger.com>
>>>
>>>> I was able to get the admin/SecurityConfig.jsp page working.  It
>>>> gives me
>>> a
>>>> ton of information - more than I can easily digest at first glance.
>>> I'll
>>>> be happy to share it with anyone who might be able to help, but I
>>>> don't
>>> feel
>>>> real comfortable sending the output to the mailing list because of
>>> security
>>>> concerns.   If nothing else, it doesn't appear to find any security
>>>> problems.
>>>>
>>>> But I guess I'm a little confused about the way the [{ALLOW view
>>>> userid}]
>>>> functions.   Since it is part of the JSPWiki page text, I would
>>>> think it
>>>> would have to be processed at the level where the page is being
>>>> viewed,
>>> not
>>>> through the security setup.   The security setup would decide
>>>> whether a
>>> user
>>>> is allowed to view or edit pages in general.   I would imagine
>>>> that the
>>>> [{ALLOW view userid}] tag works after a user is attempting to pull
>>>> up the
>>>> page in question - more at the JSPWiki level than at the security
>>>> level.
>>>>
>>>>                                              Eric R. Carlson
>>>>                                                      The Kroger
>>>> Company
>>>>
>>>> -----Original Message-----
>>>> From: Harry Metske [mailto:harry.metske@gmail.com]
>>>> Sent: Tuesday, February 10, 2009 12:25 PM
>>>> To: jspwiki-user@incubator.apache.org
>>>> Subject: Re: ALLOW tag not working properly
>>>>
>>>> Maybe you can first check a couple of things :
>>>>
>>>> Invoke the admin/SecurityConfig.jsp, it will tell you a lot about
>>>> your
>>>> security settings.
>>>> (for that to work you need to set jspwiki-
>>>> x.securityconfig.enable=true in
>>>> jspwiki.properties)
>>>>
>>>> If that does not give any clue, you should increase debug level,
>>>> you can
>>>> set
>>>> this in jspwiki.properties (at the bottom), recycle the wiki, and
>>>> see if
>>>> the
>>>> log reveals the cause of the problem.
>>>>
>>>> regards,
>>>> Harry
>>>>
>>>> 2009/2/10 Carlson, Eric R <eric.carlson@kroger.com>
>>>>
>>>>> I'm running JSPWiki 2.8.1 under z/OS 1.9 with a pretty-much
>>>> out-of-the-box
>>>>> implementation.   The only change I've made to the security
>>>>> settings is
>>>> to
>>>>> limit page edits to authenticated users.
>>>>>
>>>>> I'm trying to limit access to certain pages by issuing the
>>>>> [{ALLOW edit
>>>>> userid}] and [{ALLOW view userid}] statements in the source, but
>>>>> they
>>>> don't
>>>>> seem to be working at all.  Anybody can view or edit the page I
>>>>> create.
>>>>> I've tried putting the statements at the beginning and the end of
>>>>> the
>>>> page,
>>>>> but neither seems to make any difference.
>>>>>
>>>>> Any thoughts anybody might have would be greatly appreciated.
>>>>>
>>>>>                                              Eric Carlson
>>>>>                                                          The
>>>>> Kroger
>>>>> Company
>>>>>
>>>>>
>>>>>
>>>>> ________________________________
>>>>> This e-mail message, including any attachments, is for the sole
>>>>> use of
>>>> the
>>>>> intended recipient(s) and may contain information that is
>>>>> confidential
>>>> and
>>>>> protected by law from unauthorized disclosure. Any unauthorized
>>>>> review,
>>>> use,
>>>>> disclosure or distribution is prohibited. If you are not the
>>>>> intended
>>>>> recipient, please contact the sender by reply e-mail and destroy
>>>>> all
>>>> copies
>>>>> of the original message.
>>>>>
>>>>
>>>> This e-mail message, including any attachments, is for the sole
>>>> use of
>>> the
>>>> intended recipient(s) and may contain information that is
>>>> confidential
>>> and
>>>> protected by law from unauthorized disclosure. Any unauthorized
>>>> review,
>>> use,
>>>> disclosure or distribution is prohibited. If you are not the
>>>> intended
>>>> recipient, please contact the sender by reply e-mail and destroy
>>>> all
>>> copies
>>>> of the original message.
>>>>
>>>
>>> This e-mail message, including any attachments, is for the sole use
>>> of the
>>> intended recipient(s) and may contain information that is
>>> confidential and
>>> protected by law from unauthorized disclosure. Any unauthorized
>>> review, use,
>>> disclosure or distribution is prohibited. If you are not the
>>> intended
>>> recipient, please contact the sender by reply e-mail and destroy
>>> all copies
>>> of the original message.
>>>
>>
>> This e-mail message, including any attachments, is for the sole use
>> of the intended recipient(s) and may contain information that is
>> confidential and protected by law from unauthorized disclosure. Any
>> unauthorized review, use, disclosure or distribution is prohibited.
>> If you are not the intended recipient, please contact the sender by
>> reply e-mail and destroy all copies of the original message.
>
>
> This e-mail message, including any attachments, is for the sole use
> of the intended recipient(s) and may contain information that is
> confidential and protected by law from unauthorized disclosure. Any
> unauthorized review, use, disclosure or distribution is prohibited.
> If you are not the intended recipient, please contact the sender by
> reply e-mail and destroy all copies of the original message.


This e-mail message, including any attachments, is for the sole use of the intended recipient(s)
and may contain information that is confidential and protected by law from unauthorized disclosure.
Any unauthorized review, use, disclosure or distribution is prohibited. If you are not the
intended recipient, please contact the sender by reply e-mail and destroy all copies of the
original message.

Mime
View raw message