jspwiki-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Harry Metske <harry.met...@gmail.com>
Subject Re: ALLOW tag not working properly
Date Thu, 12 Feb 2009 19:34:44 GMT
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.
>

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message