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.carl...@kroger.com
-----Original Message-----
From: Harry Metske [mailto:harry.met...@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.carl...@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.met...@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.carl...@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.
