OK, I checked this, but SecurityImpl hasPermission is never used as they are overridden by ACLSecurityImpl which is the implementation used. So, no need to change anything here. getActionNode in NamespaceConfig *is* used, but only in initialization I guess, which should not cause any problem as well.
I have deprecated methods without tokens that access the stores in Security and getUri in Namespace. Oliver On Fri, 29 Oct 2004 10:38:47 -0700, Warwick Burrows <[EMAIL PROTECTED]> wrote: > > Oliver, > > The solution is to replace the calls to > org.apache.slide.common.Namespace.getUri(String) in both hasPermission() > methods in SecurityImpl.java with the companion method from the same class > getUri(SlideToken, String). The safest option is to replace all getUri() > calls in this way so that we don't run into the problem again. Ideally it > would be best to replace _all_ calls to getUri(String) in the entire Slide > tree and then remove the getUri(String) method so that noone can > accidentally use it in the wrong circumstances again. The only other place I > see that getUri(String) is used other than hasPermission() is in > org.apache.slide.common.NamespaceConfig in getActionNode() so if it can also > be replaced then getUri(String) can be removed. > > The trick to replacing the getUri(String) call is that you then need to have > the SlideToken for the current request handy to pass into getUri(SlideToken, > String). If it is already available in one of the parameters to > hasPermission() then great. I wasn't sure. Otherwise it may need to be > passed down the call sequence somehow or fetched from request-specific > memory. Does Slide maintain request specific context of some kind that the > SlideToken could be attached to? Then the token wouldn't have to be passed > along it could be fetched from the request specific store when needed. > > > > Warwick > > > -----Original Message----- > > From: Oliver Zeigermann [mailto:[EMAIL PROTECTED] > > Sent: Friday, October 29, 2004 11:46 AM > > To: Slide Users Mailing List > > Subject: Re: Server seems to hang on create new > > WebdavResource... (yikes, still hung) > > > > > > > Oliver, you implemented the transactional file system > > store, correct? > > > Do you know whether the other stores acquire locks at the > > start of a > > > transaction as seems to be the case with the DB store? If > > so then this > > > could be the same problem (31907) or the access control variant > > > (31908)? > > > > Yes, the tx store does locking very similar to the RDBMS > > stores. Concerning 31908, how can we fix this? Have you > > already digged into it? > > > > Oliver > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
