April 2007 - jboss-jira - Jboss List Archives

[JBoss JIRA] Created: (JBPORTAL-1193) Do-not-modify-URL-option for URLs in the WYSIWYG editor

by Nils Kassube (JIRA)

Do-not-modify-URL-option for URLs in the WYSIWYG editor ------------------------------------------------------- Key: JBPORTAL-1193 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1193 Project: JBoss Portal Issue Type: Feature Request Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.4.1 Final, 2.6.DR1 Reporter: Nils Kassube Assigned To: Roy Russo I'd like to have a "Do not modify URL" checkbox. So the URL is not munged in any way. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

3
3
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1212) Fine Grained CMS permissions not accurately enforced in a clustered environment

by Sohil Shah (JIRA)

Fine Grained CMS permissions not accurately enforced in a clustered environment ------------------------------------------------------------------------------- Key: JBPORTAL-1212 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1212 Project: JBoss Portal Issue Type: Bug Security Level: Public (Everyone can see) Components: Portal CMS Affects Versions: 2.6.Alpha1 Reporter: Sohil Shah Assigned To: Sohil Shah Fix For: 2.6.Beta1 Problem Explanation: Due to issues with JackRabbit internal caching, the PortalCMS Service is setup as a HA-Singleton service in a clustered environment. One side effect is that, when PortalCMS calls are made from nodes other than the singleton node, the User Principal is not propagated through the Singleton Proxy. Hence, the call is treated as an "Anoymous" user call instead of the currently "Logged In" User. Note: This is not an issue in a non-clustered environment -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

2
3
0 / 0

[JBoss JIRA] Created: (JBMESSAGING-947) Clustered messaging throws exceptions when failover happens in the clustered postoffice - cannot find node ID for address

by Jay Howell (JIRA)

Clustered messaging throws exceptions when failover happens in the clustered postoffice - cannot find node ID for address ------------------------------------------------------------------------------------------------------------------------- Key: JBMESSAGING-947 URL: http://jira.jboss.com/jira/browse/JBMESSAGING-947 Project: JBoss Messaging Issue Type: Bug Environment: Clusterd Messaging using Remoting 2.2.0 SP1 Reporter: Jay Howell Assigned To: Tim Fox The scenario is: - 172.26.101.67 starts messaging - 172.26.101.71 starts messaging and joins the cluster. The postoffices are now in a clustered state - Messaging on 172.26.101.71 is stopped. This causes the stack trace on 172.26.101.67 2007-04-19 15:58:46,675 DEBUG [org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice] ClusteredPostOffice[0:Clustered JMS:172.26.101.71:54179]: 172.26.101.67:52432 left 2007-04-19 15:58:46,675 ERROR [org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice] Caught Exception in MembershipListener java.lang.IllegalStateException: ClusteredPostOffice[0:Clustered JMS:172.26.101.71:54179] cannot find node ID for address 172.26.101.67:52432 at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.nodeLeft(DefaultClusteredPostOffice.java:1998) at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.access$1800(DefaultClusteredPostOffice.java:98) at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice$HandleViewAcceptedRunnable.run(DefaultClusteredPostOffice.java:2400) at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89) at java.lang.Thread.run(Thread.java:595) 2007-04-19 15:58:46,675 ERROR [STDERR] Exception in thread "Thread-28" 2007-04-19 15:58:46,675 ERROR [STDERR] java.lang.IllegalStateException: ClusteredPostOffice[0:Clustered JMS:172.26.101.71:54179] cannot find node ID for address 172.26.101.67:52432 2007-04-19 15:58:46,675 ERROR [STDERR] at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.nodeLeft(DefaultClusteredPostOffice.java:1998) 2007-04-19 15:58:46,675 ERROR [STDERR] at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice.access$1800(DefaultClusteredPostOffice.java:98) 2007-04-19 15:58:46,675 ERROR [STDERR] at org.jboss.messaging.core.plugin.postoffice.cluster.DefaultClusteredPostOffice$HandleViewAcceptedRunnable.run(DefaultClusteredPostOffice.java:2400) 2007-04-19 15:58:46,675 ERROR [STDERR] at EDU.oswego.cs.dl.util.concurrent.QueuedExecutor$RunLoop.run(QueuedExecutor.java:89) 2007-04-19 15:58:46,675 ERROR [STDERR] at java.lang.Thread.run(Thread.java:595) 2007-04-19 15:59:06,096 INFO [org.jboss.cache.TreeCache] viewAccepted(): [lonrs00341:54163|2] [lonrs00341:54163] 2007-04-19 15:59:07,046 WARN [org.jgroups.protocols.FD] ping_dest is null: members=[lonrs00337:52426 (additional data: 19 bytes), lonrs00341:5 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

3
16
0 / 0

[JBoss JIRA] Created: (JBOSGI-17) Add permissions to the ClassLoadingSystem

by Adrian Brock (JIRA)

Add permissions to the ClassLoadingSystem ----------------------------------------- Key: JBOSGI-17 URL: http://jira.jboss.com/jira/browse/JBOSGI-17 Project: JBoss OSGi Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Other Reporter: Adrian Brock Assigned To: Adrian Brock The ClassLoadingSystem (and maybe others) needs permissions on at least who can define domains and register classloaders. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBOSGI-16) Test the new ClassLoader with a SecurityManager enabled

by Adrian Brock (JIRA)

Test the new ClassLoader with a SecurityManager enabled ------------------------------------------------------- Key: JBOSGI-16 URL: http://jira.jboss.com/jira/browse/JBOSGI-16 Project: JBoss OSGi Issue Type: Sub-task Security Level: Public (Everyone can see) Components: Other Reporter: Adrian Brock Assigned To: Adrian Brock The new ClassLoader needs to be tested with a security manager enabled and add Privileged blocks where appropriate. e.g. when getting resources from imports/delegates. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBPORTAL-1368) correct word wrapping in docs pdf

by Boleslaw Dawidowicz (JIRA)

correct word wrapping in docs pdf --------------------------------- Key: JBPORTAL-1368 URL: http://jira.jboss.com/jira/browse/JBPORTAL-1368 Project: JBoss Portal Issue Type: Task Security Level: Public (Everyone can see) Components: Portal Documentation Affects Versions: 2.6.CR2 Reporter: Boleslaw Dawidowicz Assigned To: Boleslaw Dawidowicz Priority: Optional Fix For: 2.6 Final in identity docs (pdf version) for code blocks lines often go out of page. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 2 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4317) Security Context over the invocation

by Anil Saldhana (JIRA)

Security Context over the invocation ------------------------------------ Key: JBAS-4317 URL: http://jira.jboss.com/jira/browse/JBAS-4317 Project: JBoss Application Server Issue Type: Task Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-5.0.0.Beta2 Reporter: Anil Saldhana Assigned To: Anil Saldhana Fix For: JBossAS-5.0.0.Beta3 Need to move away from the SecurityAssociation usage to incorporate Security Context over the invocation. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

2
4
0 / 0

[JBoss JIRA] Created: (JBRULES-830) Migrate to MVEL Templates

by Mark Proctor (JIRA)

Migrate to MVEL Templates ------------------------- Key: JBRULES-830 URL: http://jira.jboss.com/jira/browse/JBRULES-830 Project: JBoss Rules Issue Type: Feature Request Security Level: Public (Everyone can see) Reporter: Mark Proctor Assigned To: Mark Proctor Fix For: 3.1-m2 Move the templating to MVEL, so we can drop antlr2.7.7 and StringTemplate3.0 -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
1
0 / 0

[JBoss JIRA] Created: (JBAS-4385) Bug in security cache

by Mark Sim-Smith (JIRA)

Bug in security cache --------------------- Key: JBAS-4385 URL: http://jira.jboss.com/jira/browse/JBAS-4385 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.0.4.GA Reporter: Mark Sim-Smith Assigned To: Scott M Stark I've found (I think) a reasonably serious problem with JaasSecurityManager in JBoss 4.0.4.GA around caching. It doesn't happen very often but it can result in a logged-out Subject on the stack. The root of the problem appears to be JaasSecurityManager.authenticate(), where it logs on first via defaultLogin() which results in a new SubjectContext on the stack. Authenticate() makes a subsequent call to updateCache(), which replaces the old cache entry with the new Subject, which in turn causes the LoginContext associated with the old cache entry to log out. This results in ClientLoginModule.logout() to be called, which logs out the expired Subject (by removing the Principal). It then pops the stack, which unfortunately does not result in the expired and logged-out Subject to get removed, but the recently-added Subject from defaultLogin(). This particular chain of events I would guess is mostly harmless, except in a particular situation that I find myself in: 1/ The security cache for the principal must timeout out before the web request is processed - thus we at the beginning of the request we get a Subject in the cache that has a LoginContext that is associated with a "live" Subject - it is on the stack. 2/ The security cache lookup must fail in a subsequent call within the same request where credentials do not match. Thus the getCacheInfo() call in isValid() succeeds, but validateCache() then returns false, which triggers the call to authenticate(). This happens for me when the credentials get mixed up between Strings and char[]. I've made another post on this point, but essentially ClientLoginModule generates char[] credentials, while FormAuthenticator generates Strings. The result of this unlikely combination of events is that a Subject on the stack gets logged-out so all its Principals get removed, but it remains on the stack, causing the application to fail when trying to work out who is logged in. I would love to suggest here an obvious and simple solution, but I can't see one at this stage. I have checked the head of the trunk of SVN and the relevants bits of code don't appear to have changed. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

[JBoss JIRA] Created: (JBAS-4384) Credentials should be consistently either String or char[]

by Mark Sim-Smith (JIRA)

Credentials should be consistently either String or char[] ---------------------------------------------------------- Key: JBAS-4384 URL: http://jira.jboss.com/jira/browse/JBAS-4384 Project: JBoss Application Server Issue Type: Bug Security Level: Public (Everyone can see) Components: Security Affects Versions: JBossAS-4.0.4.GA Reporter: Mark Sim-Smith Assigned To: Scott M Stark I think that I have found an issue with the representations of Credentials in JBoss - sometimes they are java.lang.String, and other times char[]. (This is for JBoss 4.0.4.GA but I think this applies to other versions - I've just checked the head of the security trunk in SVN). In particular, org.jboss.web.tomcat.security.SecurityAssociationValve uses Strings (actually the root class is probably FormAuthenticator?), and org.jboss.security.ClientLoginModule uses char[] (because it comes in from the UsernamePasswordHandler). This causes a problem with the caching, because the credentials are stored initially as a String (because of the SecurityAssociationValve), and when accessing an EJB the ClientLoginModule pushes onto the SecurityContext stack with char[] credentials, and so the cache lookup fails (org.jboss.security.plugins.JaasSecurityManager.validateCache()). As it turns out this is of little conseqence in itself because it just results in another authentication, and hits the login modules again. It happens to trigger another problem though, but I'll save that for another issue. I would suggest though that this is a minor bug - JBoss should be consistent here to avoid the additional hit on the credential cache. Probably the best approach would be to modify either the ClientLoginModule to use a String, or SecurityAssociationValve/FormAuthenticator to use a char[]. I have managed to find a workaround - to use the password-sharing option of the ClientLoginModule to pass the credentials into the ClientLoginModule as a String instead of letting the ClientLoginModule resolve the password itself via a PasswordHandler where the credentials appear as a char[] instead. This doesn't obviate the need to change JBoss to make credential handling consistent, but at least gets around my immediate problem. -- This message is automatically generated by JIRA. - If you think it was sent incorrectly contact one of the administrators: http://jira.jboss.com/jira/secure/Administrators.jspa - For more information on JIRA, see: http://www.atlassian.com/software/jira

19 years, 3 months

1
0
0 / 0

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

jboss-jira April 2007