[Beginners Corner] - Re: Secure jmx-console and web-console
by acastanheira2001
I have a jboss running on my windows desktop. In order to test the app I think that Jboss starts some products of Apache, for instance, coyote, catalina, etc...
The file apache.log appears in a log4j appender:
<appender name="apacheFileAppender" class="org.jboss.logging.appender.DailyRollingFileAppender">
| <errorHandler class="org.jboss.logging.util.OnlyOnceErrorHandler"/>
| <param name="File" value="${jboss.server.log.dir}/apache.log"/>
| <param name="Append" value="true"/>
| <param name="DatePattern" value="'.'-dd"/>
| <layout class="org.apache.log4j.PatternLayout">
| <param name="ConversionPattern" value="%d %-5p [%c{1}] %m %n"/>
| </layout>
| </appender>
And it is used by the following category:
<!-- Limit the org.apache category to INFO as its DEBUG is verbose -->
| <category name="org.apache" additivity="false">
| <priority value="INFO"/>
| <appender-ref ref="CONSOLE"/>
| <appender-ref ref="apacheFileAppender"/>
| <appender-ref ref="serverDbInfoAppender"/>
| </category>
|
Any ideias about the stack trace?
Thanks,
Andre
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213851#4213851
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213851
17 years, 1 month
[Security & JAAS/JBoss] - Re: GenericHeaderBasedAuthentication
by sfisque
"anil.saldhana(a)jboss.com" wrote : httpHeaderForSSOAuth="sm_ssoid,ct-remote-user,HTTP_OBLIX_UID"
| | sessionCookieForSSOAuth="SMSESSION,CTSESSION,ObSSOCookie"
|
| The first value is basically what oblix will be sending as the username in the http header. The second one is what oblix will use as a session cookie. Do you have the header names passed by oblix?
i dug up the source so it appears the comma delimited list is a multiple choice of possible values the driver looks for.
from what i've gathered from the client, the Header is going to be XYZUSER. they are not going to push the session_id (they say we should just trust the user_id published in the Header).
i've configured my context.xml to have the valve in question. problem is, i tried to request the main page using curl and pushing the Header with a value that maps to a user in the app user table (we use the DatabaseServerLoginModule to handle mapping users and roles) but it always sends me the login page.
what i was expecting (maybe erroneously) that the GenericHeaderAuthenticator would intercept the request for the form and inject the user_id from the Header and then the DatabaseServerLoginModule (configured with "useFirstPass") would recognize we have a user_id and just map the roles.
my followup questions are:
1) if we are using an application policy in login-config.xml, does this negate the Valve in the context.xml or do they not play nicely together, requiring me to create a JAAS module and configure it in the login-config.xml?
2) if JAAS and the GenericHeader valve do not play nicely, can the GenericHeader be configured as a login module in login-config.xml?
TIA
== stanton
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213848#4213848
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213848
17 years, 1 month
[JBoss Getting Started Documentation] - JBoss5 - Legacy applications and descriptor compatibility
by brent.atkinson
Hi,
I am an long-time JBoss AS 4 user and I having a bit of trouble deciphering my deployment issues on JBoss AS 5. What I am finding is that the JBoss specific deployment descriptors are causing the deployers to reject the deployments. The error that they are exhibiting is:
Caused by: org.jboss.xb.binding.JBossXBRuntimeException: -1:-1 94:3 The markup in the document preceding the root element must be well-formed.
| at org.jboss.xb.binding.sunday.unmarshalling.XsdBinderTerminatingErrorHandler.handleError(XsdBinderTerminatingErrorHandler.java:40)
| at org.apache.xerces.impl.xs.XMLSchemaLoader.reportDOMFatalError(Unknown Source)
| at org.apache.xerces.impl.xs.XSLoaderImpl.load(Unknown Source)
| at org.jboss.xb.binding.Util.loadSchema(Util.java:395)
| at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:175)
| at org.jboss.xb.binding.sunday.unmarshalling.XsdBinder.bind(XsdBinder.java:146)
| at org.jboss.xb.binding.sunday.unmarshalling.DefaultSchemaResolver.resolve(DefaultSchemaResolver.java:332)
| ... 51 more
I searched google and the JBoss community resources wiki/documentation/forums and the only reference I found to this indicates issues with poorly formed documents. However, I have checked the structure and validated the document with the specified DTD.
An example document:
<?xml version="1.0" encoding="UTF-8"?>
| <!DOCTYPE jboss PUBLIC "-//JBoss//DTD JBOSS 2.4//EN" "http://www.jboss.org/j2ee/dtd/jboss_2_4.dtd">
| <jboss>
| <enterprise-beans>
| <session>
| <ejb-name>MyBean</ejb-name>
| <jndi-name>ejb/MyBean</jndi-name>
| <resource-ref>
| <res-ref-name>jdbc/EntityDB</res-ref-name>
| <jndi-name>java:jdbc/EntityDB</jndi-name>
| </resource-ref>
| </session>
| </enterprise-beans>
| <resource-managers>
| </resource-managers>
| </jboss>
Does anyone know why is JBoss 5 kicking this out? I have successfully deployed the application components by removing the DTD declarations altogether, but I'd really like to get to the root cause of the issue.
Does JBoss 5 not support the legacy DTDs? If not, then why are they included in the docs/dtds directory of the installation?
Any help will be greatly appreciated.
Thanks,
Brent
View the original post : http://www.jboss.org/index.html?module=bb&op=viewtopic&p=4213845#4213845
Reply to the post : http://www.jboss.org/index.html?module=bb&op=posting&mode=reply&p=4213845
17 years, 1 month