[JBoss JIRA] Created: (JBPORTAL-1751) portlet-instances.xml security-constraints are not verified using request.isUserInRole()
by Johannes Fiala (JIRA)
portlet-instances.xml security-constraints are not verified using request.isUserInRole()
----------------------------------------------------------------------------------------
Key: JBPORTAL-1751
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1751
Project: JBoss Portal
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Portal Security
Affects Versions: 2.6.2 Final, 2.6.1 Final
Environment: Java JDK 1.4.2
Reporter: Johannes Fiala
Assigned To: Julien Viet
The implementation which verifies the security of portlet-instances.xml against the user roles currently doesn't seem to use request.isUserInRole().
Fact 1:
If you use a role-link in the portlet.xml (to have a role which is not originally created by the Jboss Portal Loginmodule (IdentityLoginModule))
<portlet>
...
<security-role-ref>
<role-name>PortletUser</role-name>
<role-link>User</role-link>
</security-role-ref>
</portlet>
and then use it in the portlet-instances.xml:
<instance>
...
<security-constraint>
<policy-permission>
<role-name>PortletUser</role-name>
<action-name>view</action-name>
</policy-permission>
</security-constraint>
</instance>
</deployment>
the portlet instance will not show up.
If you use the User-role instead, it works correctly.
However, if I do a request.isUserInRole("PortletUser") in the portlet itself, it will always show up as expected.
Fact 2:
Additionally, it seems the portlet-instances.xml- security check also makes use of the org.jboss.portal.identity.auth.UserPrincipal.
I wrote a custom loginmodule and added the "User"-role using my own Principal-class. Again, the portlet instance doesn't show up with my custom loginmodule.
If I check it using request.isUserInRole("User"), it shows up correctly.
--
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
18 years, 1 month
[JBoss JIRA] Created: (JBBUILD-429) Port [JBBUILD-428 - Add support for ThreadLocal.remove()] to JBossRetro1.0.4.GA
by Magesh Kumar B (JIRA)
Port [JBBUILD-428 - Add support for ThreadLocal.remove()] to JBossRetro1.0.4.GA
-------------------------------------------------------------------------------
Key: JBBUILD-429
URL: http://jira.jboss.com/jira/browse/JBBUILD-429
Project: JBoss Build System
Issue Type: Support Patch
Components: JBossRetro
Environment: JBoss4.0.5GA + JBossWS1.2.1.GA + JBWS-1860 + JDK1.4
Reporter: Magesh Kumar B
Assigned To: Magesh Kumar B
Priority: Blocker
When the above combination is used the JBossWS DOMUtils throws the following exception:
java.lang.NullPointerException
at org.jboss.ws.core.utils.DOMUtils.getOwnerDocument(DOMUtils.java:529)
at org.jboss.ws.core.soap.SOAPDocument.<init>(SOAPDocument.java:55)
at org.jboss.ws.core.soap.SOAPPartImpl.<init>(SOAPPartImpl.java:77)
at org.jboss.ws.core.soap.SOAPMessageImpl.<init>(SOAPMessageImpl.java:66)
at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:243)
at org.jboss.ws.core.soap.MessageFactoryImpl.createMessage(MessageFactoryImpl.java:179)
at org.jboss.ws.core.server.ServiceEndpoint.processRequest(ServiceEndpoint.java:197)
at org.jboss.ws.core.server.ServiceEndpointManager.processRequest(ServiceEndpointManager.java:449)
at org.jboss.ws.core.server.AbstractServiceEndpointServlet.doPost(AbstractServiceEndpointServlet.java:114)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:717)
at org.jboss.ws.core.server.AbstractServiceEndpointServlet.service(AbstractServiceEndpointServlet.java:75)
at javax.servlet.http.HttpServlet.service(HttpServlet.java:810)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:252)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.jboss.web.tomcat.filters.ReplyHeaderFilter.doFilter(ReplyHeaderFilter.java:96)
at org.apache.catalina.core.ApplicationFilterChain.internalDoFilter(ApplicationFilterChain.java:202)
at org.apache.catalina.core.ApplicationFilterChain.doFilter(ApplicationFilterChain.java:173)
at org.apache.catalina.core.StandardWrapperValve.invoke(StandardWrapperValve.java:213)
at org.apache.catalina.core.StandardContextValve.invoke(StandardContextValve.java:178)
at org.jboss.web.tomcat.security.SecurityAssociationValve.invoke(SecurityAssociationValve.java:175)
at org.jboss.web.tomcat.security.JaccContextValve.invoke(JaccContextValve.java:74)
at org.apache.catalina.core.StandardHostValve.invoke(StandardHostValve.java:126)
at org.apache.catalina.valves.ErrorReportValve.invoke(ErrorReportValve.java:105)
at org.jboss.web.tomcat.tc5.jca.CachedConnectionValve.invoke(CachedConnectionValve.java:156)
at org.apache.catalina.core.StandardEngineValve.invoke(StandardEngineValve.java:107)
at org.apache.catalina.connector.CoyoteAdapter.service(CoyoteAdapter.java:148)
at org.apache.coyote.http11.Http11Processor.process(Http11Processor.java:869)
at org.apache.coyote.http11.Http11BaseProtocol$Http11ConnectionHandler.processConnection(Http11BaseProtocol.java:664)
at org.apache.tomcat.util.net.PoolTcpEndpoint.processSocket(PoolTcpEndpoint.java:527)
at org.apache.tomcat.util.net.MasterSlaveWorkerThread.run(MasterSlaveWorkerThread.java:112)
at java.lang.Thread.run(Thread.java:534)
This is due to the fact that jboss-retro sets null to the ThreadLocal's that are removed.
--
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
18 years, 1 month
[JBoss JIRA] Created: (JBPORTAL-1820) Finders for user profile
by Andrew Oliver (JIRA)
Finders for user profile
------------------------
Key: JBPORTAL-1820
URL: http://jira.jboss.com/jira/browse/JBPORTAL-1820
Project: JBoss Portal
Issue Type: Sub-task
Security Level: Public (Everyone can see)
Components: Portal Identity
Reporter: Andrew Oliver
It should be possible to search for users by properties of their profile. Example all users with location "Heidelberg, DE" or other user added properties.
Add
User findUserByProfileProperty(String name, Object value); to UserProfileModule and its implementations
Alter HibernateUserImpl such that ProfileMap is an Entity able to be searched on. Presently this is JBP_USER_PROP but is a component. This can be altered without altering the database structure and without more than mapping and other minor changes to the Hibernate...Impl classes (none of which would affect existing portal apps).
--
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
18 years, 1 month
[JBoss JIRA] Created: (JBAS-5015) Deploy entity beans in Oracle 11g on JBoss 4.2.1 and JBoss 4.2.1
by Georges Goebel (JIRA)
Deploy entity beans in Oracle 11g on JBoss 4.2.1 and JBoss 4.2.1
----------------------------------------------------------------
Key: JBAS-5015
URL: http://jira.jboss.com/jira/browse/JBAS-5015
Project: JBoss Application Server
Issue Type: Bug
Security Level: Public (Everyone can see)
Components: Hibernate service
Affects Versions: JBossAS-4.2.2.GA, JBossAS-4.2.1.GA
Environment: JAva 1.5
JBoss 4.2.1 and JBoss4.2.2
Reporter: Georges Goebel
Assigned To: Steve Ebersole
It is not possible to deploy entity beans to an Oracle 11g Datasource because the HibernateException :
unknown Oracle major version [11] occurs
If I check in the hibernate 3.2.4sp1 distribution the class org.hibernate.dialect.DialectFactory there I find the following definition which is correct (in my eyes)
private static final Map MAPPERS = new HashMap();
static {
// TODO : this is the stuff it'd be nice to move to a properties file or some other easily user-editable place
MAPPERS.put( "HSQL Database Engine", new VersionInsensitiveMapper( "org.hibernate.dialect.HSQLDialect" ) );
MAPPERS.put( "DB2/NT", new VersionInsensitiveMapper( "org.hibernate.dialect.DB2Dialect" ) );
MAPPERS.put( "MySQL", new VersionInsensitiveMapper( "org.hibernate.dialect.MySQLDialect" ) );
MAPPERS.put( "PostgreSQL", new VersionInsensitiveMapper( "org.hibernate.dialect.PostgreSQLDialect" ) );
MAPPERS.put( "Microsoft SQL Server Database", new VersionInsensitiveMapper( "org.hibernate.dialect.SQLServerDialect" ) );
MAPPERS.put( "Microsoft SQL Server", new VersionInsensitiveMapper( "org.hibernate.dialect.SQLServerDialect" ) );
MAPPERS.put( "Sybase SQL Server", new VersionInsensitiveMapper( "org.hibernate.dialect.SybaseDialect" ) );
MAPPERS.put( "Informix Dynamic Server", new VersionInsensitiveMapper( "org.hibernate.dialect.InformixDialect" ) );
MAPPERS.put( "Apache Derby", new VersionInsensitiveMapper( "org.hibernate.dialect.DerbyDialect" ) );
MAPPERS.put(
"Oracle",
new DatabaseDialectMapper() {
public String getDialectClass(int majorVersion) {
return majorVersion > 8
? "org.hibernate.dialect.Oracle9Dialect"
: "org.hibernate.dialect.OracleDialect";
}
}
);
}
The JBoss 4.2.2 distribution shows during startup the usage of hibernate 3.2.4sp1 (also according the Manifest file in the jar) but when I decompile the class org.hibernate.dialect.DialectFactory in the JBoss distribution it shows the old implementation:
static
{
MAPPERS = new HashMap();
MAPPERS.put("HSQL Database Engine", new VersionInsensitiveMapper("org.hibernate.dialect.HSQLDialect"));
MAPPERS.put("DB2/NT", new VersionInsensitiveMapper("org.hibernate.dialect.DB2Dialect"));
MAPPERS.put("DB2/LINUX", new VersionInsensitiveMapper("org.hibernate.dialect.DB2Dialect"));
MAPPERS.put("MySQL", new VersionInsensitiveMapper("org.hibernate.dialect.MySQLDialect"));
MAPPERS.put("PostgreSQL", new VersionInsensitiveMapper("org.hibernate.dialect.PostgreSQLDialect"));
MAPPERS.put("Microsoft SQL Server Database", new VersionInsensitiveMapper("org.hibernate.dialect.SQLServerDialect"));
MAPPERS.put("Microsoft SQL Server", new VersionInsensitiveMapper("org.hibernate.dialect.SQLServerDialect"));
MAPPERS.put("Sybase SQL Server", new VersionInsensitiveMapper("org.hibernate.dialect.SybaseDialect"));
MAPPERS.put("Adaptive Server Enterprise", new VersionInsensitiveMapper("org.hibernate.dialect.SybaseDialect"));
MAPPERS.put("Informix Dynamic Server", new VersionInsensitiveMapper("org.hibernate.dialect.InformixDialect"));
MAPPERS.put("Apache Derby", new VersionInsensitiveMapper("org.hibernate.dialect.DerbyDialect"));
MAPPERS.put("Oracle", new DatabaseDialectMapper() {
public String getDialectClass(int majorVersion)
{
switch(majorVersion)
{
case 8: // '\b'
return (DialectFactory.class$org$hibernate$dialect$Oracle8iDialect != null ? DialectFactory.class$org$hibernate$dialect$Oracle8iDialect : (DialectFactory.class$org$hibernate$dialect$Oracle8iDialect = DialectFactory._mthclass$("org.hibernate.dialect.Oracle8iDialect"))).getName();
case 9: // '\t'
return (DialectFactory.class$org$hibernate$dialect$Oracle9iDialect != null ? DialectFactory.class$org$hibernate$dialect$Oracle9iDialect : (DialectFactory.class$org$hibernate$dialect$Oracle9iDialect = DialectFactory._mthclass$("org.hibernate.dialect.Oracle9iDialect"))).getName();
case 10: // '\n'
return (DialectFactory.class$org$hibernate$dialect$Oracle10gDialect != null ? DialectFactory.class$org$hibernate$dialect$Oracle10gDialect : (DialectFactory.class$org$hibernate$dialect$Oracle10gDialect = DialectFactory._mthclass$("org.hibernate.dialect.Oracle10gDialect"))).getName();
}
throw new HibernateException("unknown Oracle major version [" + majorVersion + "]");
}
});
}
Perhaps there is something wrong by integration the different components in JBoss during packaging.
Replacing the hibernate3.jar in the JBoss distribution by the hibernate3.jar from the hibernate 3.2.4sp1 distribution solved the 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
18 years, 1 month
[JBoss JIRA] Commented: (JBWEB-16) scratchdir fails for multi-user installs
by Remy Maucherat (JIRA)
[ http://jira.jboss.com/jira/browse/JBWEB-16?page=comments#action_12389596 ]
Remy Maucherat commented on JBWEB-16:
-------------------------------------
The only real option to make it automagical is to use a random folder name inside temp, but this does not work well as there's a possible expectation by some users that the work folder is persistent (it can be used for session persistence, keeping compiled JSPs, etc). Using "catalina.base" uses Tomcat's multi-user capabilities, which makes it work.
Unless someone comes up with a brilliant idea, I'll resolve this as "won't fix".
> scratchdir fails for multi-user installs
> ----------------------------------------
>
> Key: JBWEB-16
> URL: http://jira.jboss.com/jira/browse/JBWEB-16
> Project: JBoss Web
> Issue Type: Bug
> Security Level: Public(Everyone can see)
> Components: Tomcat Module
> Affects Versions: JBossWeb embedded - AS 4.0.1
> Reporter: Norman Richards
> Assigned To: Remy Maucherat
>
> The setup was the basic multi-user scenario described in the dev environment admin training slides (module 8). Each user has his own data/tmp/deploy directory, but the conf directory is shared between all users and not writable.
> This produces a a FATAL log message:
> 11:37:06,717 FATAL [EmbeddedServletOptions] The scratchDir you specified:
> /private/tmp/jboss-4.0.2/server/test/work/jboss.web/localhost/jmx-console is unusable.
> This also causes exceptions when the server shuts down.
> The jboss.web directory should probably go under the data or tmp directory so that it can exist on a per-user basis. Another option is to allow variable substitution in the server.xml file so that the scratchdir can be set based on the $[user.name} property.
> See the admin module 8, slides 5-16 for the complete configuration if my description isn't clear.
--
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
18 years, 1 month
[JBoss JIRA] Created: (JGRP-634) Ability to add stacks to JChannelFactory
by Brian Stansberry (JIRA)
Ability to add stacks to JChannelFactory
----------------------------------------
Key: JGRP-634
URL: http://jira.jboss.com/jira/browse/JGRP-634
Project: JGroups
Issue Type: Feature Request
Reporter: Brian Stansberry
Assigned To: Bela Ban
Priority: Minor
It would be nice to be able to add additional stacks to an existing JChannelFactory.
Example: an AS deployment that wants to use a specialized channel. The deployment could package an "added-stacks.xml" file and a -beans.xml file that declares something like this:
<bean>
<!-- Add our stacks to the app server's standard JChannelFactory -->
<install bean="JChannelFactory" method="addMultiplexerConfig">
<parameter>added-stacks.xml</parameter>
</install>
</bean>
Other services in the deployment would then be able to use some custom stack declared in added-stacks.xml.
The nice thing about this is it allows packaging of custom stacks with the deployment that uses them, rather than forcing an edit of a global stacks.xml file.
A quick look at JChannelFactory tells me this should be pretty simple to do. The existing setMultiplexerConfig methods seem to work like "add" methods, i.e. they could be invoked multiple times with different passed in values. A minor exception is setMultiplexerConfig(String) which also caches the passed String in an instance field. So, it should be simple to add addMultiplexerConfig methods that basically invoke the same logic.
They should probably be added to the jmx.JChannelFactory as well.
--
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
18 years, 1 month