[Security & JAAS/JBoss] - Big authentication problem: not being redirected to the logi
by Marcos_APS
- JBoss 4.2.3.GA
Hello, everybody!
I've just noticed a big problem in the web application I'm developing. In this application I'm using the FORM authentication method as you can see below in the web.xml file:
<security-constraint>
| <web-resource-collection>
| <web-resource-name>permitido</web-resource-name>
| <url-pattern>/*</url-pattern>
| </web-resource-collection>
| <user-data-constraint>
| <transport-guarantee>NONE</transport-guarantee>
| </user-data-constraint>
| </security-constraint>
|
| <security-constraint>
| <web-resource-collection>
| <web-resource-name>restrito</web-resource-name>
| <url-pattern>/confirmacaoreserva.jsp</url-pattern>
| <url-pattern>/confirmacaoreserva.faces</url-pattern>
| <url-pattern>/reservaconfirmada.jsp</url-pattern>
| <url-pattern>/reservaconfirmada.faces</url-pattern>
| </web-resource-collection>
| <auth-constraint>
| <role-name>ADMINISTRADOR</role-name>
| <role-name>USUARIO</role-name>
| </auth-constraint>
| <user-data-constraint>
| <transport-guarantee>NONE</transport-guarantee>
| </user-data-constraint>
| </security-constraint>
|
| <login-config>
| <auth-method>FORM</auth-method>
| <form-login-config>
| <form-login-page>/login.jsp</form-login-page>
| <form-error-page>/errologin.jsp</form-error-page>
| </form-login-config>
| </login-config>
|
| <security-role>
| <role-name>ADMINISTRADOR</role-name>
| </security-role>
| <security-role>
| <role-name>USUARIO</role-name>
| </security-role>
If I type in the browser's address field any of the protected pages,
confirmacaoreserva.faces or reservaconfirmada.faces, the web container redirects me to the login page as expected, as I was'n authenticated yet. Until till this point everything is working without problem. But I noticed, to my surprise, that when I click on a link in a web page like this:
<h:commandLink value="#{msg.reservar}" action="#{materiais.reservarMaterial}">
| <f:setPropertyActionListener target="#{materiais.codigoMaterial}" value="#{material.codigo}" />
| </h:commandLink>
// in the backing bean
| public String reservarMaterial()
| {
| // some processing...
| return "confirmacaoReserva";
| }
// in faces-config.xml
| <navigation-rule>
| <navigation-case>
| <from-outcome>confirmacaoReserva</from-outcome>
| <to-view-id>/confirmacaoreserva.jsp</to-view-id>
| </navigation-case>
| </navigation-rule>
it completely by-passes the web container authentication and redirects me to the protected page (confirmacaoreserva) without asking me first to authenticate in the login page. Of course this is unacceptable. It seems like JSF is completely ignoring the security configuration defined in web.xml. As I said above, when I access the protected pages through the browser's address field, the authentication mechanism works well, redirecting me to the login page.
So, how can I solve this? How do I fix this problem?
Thank you.
Marcos
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188183#4188183
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188183
17 years, 8 months
[Persistence, JBoss/CMP, Hibernate, Database] - JPA with hypersonice db
by bfach
Hello,
I am trying to deploy to separate datasources in jboss (both hypersonic db) for testing. We have already done this for oracle however I am getting an error when using hypersonic.
The first datasource is for application data, the second for jboss messaging.
I get the following when i start up jboss
2008-11-07 11:38:22,987 WARN [org.jboss.system.ServiceController] Problem starting service jboss.messaging:service=JMSUserManager
org.jboss.util.NestedSQLException: No matching credentials in Subject!; - nested throwable: (org.jboss.resource.JBossResourceException: No matching credentials in Subject!)
at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:94)
at org.jboss.messaging.core.impl.JDBCSupport.createSchema(JDBCSupport.java:280)
at org.jboss.messaging.core.impl.JDBCSupport.start(JDBCSupport.java:160)
at org.jboss.jms.server.plugin.JDBCJMSUserManager.start(JDBCJMSUserManager.java:98)
at org.jboss.jms.server.plugin.JDBCJMSUserManagerService.startService(JDBCJMSUserManagerService.java:78)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.start(ServiceMBeanSupport.java:196)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:995)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at org.jboss.system.ServiceController.start(ServiceController.java:435)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy51.start(Unknown Source)
at org.jboss.deployment.XSLSubDeployer.start(XSLSubDeployer.java:197)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at sun.reflect.GeneratedMethodAccessor28.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy9.deploy(Unknown Source)
at org.jboss.deployment.scanner.URLDeploymentScanner.deploy(URLDeploymentScanner.java:421)
at org.jboss.deployment.scanner.URLDeploymentScanner.scan(URLDeploymentScanner.java:634)
at org.jboss.deployment.scanner.AbstractDeploymentScanner$ScannerThread.doScan(AbstractDeploymentScanner.java:263)
at org.jboss.deployment.scanner.AbstractDeploymentScanner.startService(AbstractDeploymentScanner.java:336)
at org.jboss.system.ServiceMBeanSupport.jbossInternalStart(ServiceMBeanSupport.java:289)
at org.jboss.system.ServiceMBeanSupport.jbossInternalLifecycle(ServiceMBeanSupport.java:245)
at sun.reflect.GeneratedMethodAccessor3.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.system.ServiceController$ServiceProxy.invoke(ServiceController.java:978)
at $Proxy0.start(Unknown Source)
at org.jboss.system.ServiceController.start(ServiceController.java:417)
at sun.reflect.GeneratedMethodAccessor9.invoke(Unknown Source)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:86)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy4.start(Unknown Source)
at org.jboss.deployment.SARDeployer.start(SARDeployer.java:302)
at org.jboss.deployment.MainDeployer.start(MainDeployer.java:1025)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:819)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:782)
at org.jboss.deployment.MainDeployer.deploy(MainDeployer.java:766)
at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)
at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)
at java.lang.reflect.Method.invoke(Method.java:585)
at org.jboss.mx.interceptor.ReflectedDispatcher.invoke(ReflectedDispatcher.java:155)
at org.jboss.mx.server.Invocation.dispatch(Invocation.java:94)
at org.jboss.mx.interceptor.AbstractInterceptor.invoke(AbstractInterceptor.java:133)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.interceptor.ModelMBeanOperationInterceptor.invoke(ModelMBeanOperationInterceptor.java:142)
at org.jboss.mx.server.Invocation.invoke(Invocation.java:88)
at org.jboss.mx.server.AbstractMBeanInvoker.invoke(AbstractMBeanInvoker.java:264)
at org.jboss.mx.server.MBeanServerImpl.invoke(MBeanServerImpl.java:659)
at org.jboss.mx.util.MBeanProxyExt.invoke(MBeanProxyExt.java:210)
at $Proxy5.deploy(Unknown Source)
at org.jboss.system.server.ServerImpl.doStart(ServerImpl.java:482)
at org.jboss.system.server.ServerImpl.start(ServerImpl.java:362)
at org.jboss.Main.boot(Main.java:200)
at org.jboss.Main$1.run(Main.java:508)
at java.lang.Thread.run(Thread.java:595)
Caused by: org.jboss.resource.JBossResourceException: No matching credentials in Subject!
at org.jboss.resource.adapter.jdbc.BaseWrapperManagedConnectionFactory.getConnectionProperties(BaseWrapperManagedConnectionFactory.java:381)
at org.jboss.resource.adapter.jdbc.local.LocalManagedConnectionFactory.createManagedConnection(LocalManagedConnectionFactory.java:149)
at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.createConnectionEventListener(InternalManagedConnectionPool.java:577)
at org.jboss.resource.connectionmanager.InternalManagedConnectionPool.getConnection(InternalManagedConnectionPool.java:262)
at org.jboss.resource.connectionmanager.JBossManagedConnectionPool$BasePool.getConnection(JBossManagedConnectionPool.java:538)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.getManagedConnection(BaseConnectionManager2.java:341)
at org.jboss.resource.connectionmanager.TxConnectionManager.getManagedConnection(TxConnectionManager.java:315)
at org.jboss.resource.connectionmanager.BaseConnectionManager2.allocateConnection(BaseConnectionManager2.java:396)
at org.jboss.resource.connectionmanager.BaseConnectionManager2$ConnectionManagerProxy.allocateConnection(BaseConnectionManager2.java:842)
at org.jboss.resource.adapter.jdbc.WrapperDataSource.getConnection(WrapperDataSource.java:88)
... 119 more
The hsqldb.xml is as follows
<?xml version="1.0" encoding="UTF-8"?>
<!-- The Hypersonic embedded database JCA connection factory config -->
<!-- $Id: hsqldb-ds.xml 63175 2007-05-21 16:26:06Z rrajesh $ -->
<local-tx-datasource>
<!-- The jndi name of the DataSource, it is prefixed with java:/ -->
<jndi-name>DefaultDS</jndi-name>
<connection-url>jdbc:hsqldb:${jboss.server.data.dir}${/}hypersonic${/}localDB</connection-url>
<!-- The driver class -->
<driver-class>org.hsqldb.jdbcDriver</driver-class>
<!-- The login and password -->
<user-name>sa</user-name>
<min-pool-size>5</min-pool-size>
<max-pool-size>20</max-pool-size>
<idle-timeout-minutes>0</idle-timeout-minutes>
<security-domain>HsqlDbRealm</security-domain>
<prepared-statement-cache-size>32</prepared-statement-cache-size>
<type-mapping>Hypersonic SQL</type-mapping>
</local-tx-datasource>
<local-tx-datasource>
<!-- Datasources are not available outside the virtual machine -->
<jndi-name>JBossDS</jndi-name>
<connection-url>jdbc:hsqldb:${jboss.server.data.dir}${/}hypersonic${/}JBossDB</connection-url>
<!-- The driver class -->
<driver-class>org.hsqldb.jdbcDriver</driver-class>
<!-- The login and password -->
<user-name>sa</user-name>
<!-- The minimum connections in a pool/sub-pool. Pools are lazily constructed on first use -->
<min-pool-size>5</min-pool-size>
<max-pool-size>20</max-pool-size>
<idle-timeout-minutes>0</idle-timeout-minutes>
<security-domain>HsqlDbRealm</security-domain>
<prepared-statement-cache-size>32</prepared-statement-cache-size>
<type-mapping>Hypersonic SQL</type-mapping>
</local-tx-datasource>
localDB
true
jbossDB
true
When i check the jmx console, both datasources are deployed however there is an issue with messaging using this datasource.
Any help would be greatly appreciated.
Thanks,
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188178#4188178
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188178
17 years, 8 months
[Installation, Configuration & DEPLOYMENT] - EJB not deployed in EAR file with libraries
by antonio.genghi
Hi all.
I have a strage problem with JBoss 4.2.3 running on JDK 1.5.0_16b02 (latest from Sun).
Here is my case:
myApp.ear
|
|\-lib
| \-util1.jar
| |-util2.jar
|
|\-META-INF
| \-application.xml
| |-MANIFEST.MF
|
|-myEjb.jar
Content of application.xml:
<?xml version="1.0" encoding="UTF-8"?>
| <!DOCTYPE application PUBLIC '-//Sun Microsystems, Inc.//DTD J2EE Application 1.3//EN' 'http://java.sun.com/dtd/application_1_3.dtd'>
| <application>
| <display-name>myApp</display-name>
| <description>Application description</description>
| <module>
| <ejb>myEjb.jar</ejb>
| </module>
| <library-directory>lib</library-directory>
| </application>
Content of MANIFEST.MF
Manifest-Version: 1.0
| Ant-Version: Apache Ant 1.7.0
| Created-By: 1.5.0_16-b02 (Sun Microsystems Inc.)
myEJB.jar
|
|\-myPackage
| \-myBean.class
|
|\-META-INF
| \-ejb-jar.xml
| |-jboss.xml
| |-MANIFEST.MF
Content of ejb-jar.xml
<?xml version="1.0" encoding="UTF-8"?>
| <!DOCTYPE ejb-jar PUBLIC '-//Sun Microsystems, Inc.//DTD Enterprise JavaBeans 2.0//EN' 'http://java.sun.com/dtd/ejb-jar_2_0.dtd'>
| <ejb-jar>
| <display-name>myEJB</display-name>
| <enterprise-beans>
| <message-driven>
| <display-name>myEJB</display-name>
| <ejb-name>myEJB</ejb-name>
| <ejb-class>myPackage.myBean</ejb-class>
| <transaction-type>Container</transaction-type>
| <message-driven-destination>
| <destination-type>javax.jms.Queue</destination-type>
| </message-driven-destination>
| </message-driven>
| </enterprise-beans>
| </ejb-jar>
Content of jboss.xml
| <?xml version="1.0" encoding="UTF-8"?>
| <!DOCTYPE jboss PUBLIC
| "-//JBoss//DTD JBOSS 3.2//EN"
| "http://www.jboss.org/j2ee/dtd/jboss_3_2.dtd">
| <jboss>
| <enterprise-beans>
| <message-driven>
| <ejb-name>myEJB</ejb-name>
| <destination-jndi-name>jms/myQueue</destination-jndi-name>
| </message-driven>
| </enterprise-beans>
| </jboss>
|
Content of MANIFEST.MF
| Manifest-Version: 1.0
| Ant-Version: Apache Ant 1.7.0
| Created-By: 1.4.2_05-b04 (Sun Microsystems Inc.)
| Class-Path:
| util1.jar
| util2.jar
| Ant-Version: Apache Ant
| 1.6.5
|
(It should be all).
The problem is that i cannot see th EJB deployed neither bind to JMS queue.
But if i try to deploy the whole EAR without the util1.jar and util2.jar (also removing from manifest.mf) the EJB deploy correctly and bind to jms quee too.
Also, the EAR and EJB works correctly if i deploy the archive as an exploded package (also the myEjb.jar).
The picture was not so clear so i decided to debug the JARDeployer, and i notice that the problem is in those lines:
| // Since a META-INF directory exists within rt.jar, we can't just do a
| // getResource (it will always return rt.jar's version).
| // The method we want is findResource, but it is marked protected in
| // ClassLoader. Fortunately, URLClassLoader exposes it which makes
| // this hack possible. Anybody have a better way to check a URL
| // for the existance of a META-INF??
| URL ddDir;
| try
| {
| ddDir = di.localCl.findResource("META-INF/");
| if (ddDir == null)
| {
| log.debug("No META-INF or WEB-INF resource found, assuming it if for us");
| return true;
| }
| }
| catch (ClassCastException e)
| {
| // assume there is a META-INF...
| ddDir = new URL(di.url, "META-INF/");
| }
|
The deployer (better, the classloader) cannot access META-INF of myEJB.jar in the temp deploy directory.
The question is: WHY?
Where am I wrong?
Could you help me?
Thanks a lot in advance.
Antonio
View the original post : http://www.jboss.com/index.html?module=bb&op=viewtopic&p=4188177#4188177
Reply to the post : http://www.jboss.com/index.html?module=bb&op=posting&mode=reply&p=4188177
17 years, 8 months