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
                                       [email protected]


-----Original Message-----
From: Harry Metske [mailto:[email protected]]
Sent: Thursday, February 12, 2009 2:35 PM
To: [email protected]
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 <[email protected]>

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
                              [email protected]


-----Original Message-----
From: Harry Metske [mailto:[email protected]]
Sent: Thursday, February 12, 2009 12:09 PM
To: [email protected]
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 <[email protected]>

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:[email protected]]
Sent: Tuesday, February 10, 2009 12:25 PM
To: [email protected]
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 <[email protected]>

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.

Reply via email to