incubator-jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Janne Jalkanen <Janne.Jalka...@ecyrd.com>
Subject Re: ALLOW tag not working properly
Date Thu, 12 Feb 2009 21:05:15 GMT

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.


Mime
View raw message