Tag Archives: JBoss

mod_rewrite to bypass security

Posted on by
Reply

Many Apache webserver installations use uriworkermap to configure requests are forwarded to Tomcat/JBoss and which are not.   This provides a certain level of security.  For example:

## APACHE RESOURCES (static files):
!/*.gif=myapp
!/*.html=myapp

## DISALLOW  (security-related filter):
!/*.jsp=myapp
!/*.xml=myapp

## TOMCAT RESOURCES:
/*.do=myapp

However if you dynamically generate your sitemap.xml or any other XML files using a servlet then this security will be a problem since the XML request will not make it to Tomcat/JBoss.  This is when mod_rewrite comes to the rescue.

You can set up mod_rewrite to rewrite the sitemap.xml request to be a sitemap.do request.

RewriteRule ^/sitemap\.xml$ /sitemap.do [PT,L]

Then you can set up Struts to forward this request to sitemap.xml.

<action path="/sitemap" forward="/sitemap.xml"/>

Turning off JSP access

Posted on by
Reply

To turn off JSP access in your JBoss or other favorite application server add this to your web.xml.

<!-- Restrict direct access to jsps -->
<security-constraint>
  <web-resource-collection>
    <web-resource-name>you_cant_touch_this</web-resource-name>
    <url-pattern>*.jsp</url-pattern>
  </web-resource-collection>
  <auth-constraint/>
</security-constraint>

To prevent Apache from sending JSP requests to JBoss add the following to your configuration.

## DISALLOW FROM REACHING JBOSS (security-related filter):
!/*.jsp=name_of_your_app
!/*.xml=name_of_your_app

Mysterious dspel:include problem with flush=true

Posted on by
Reply

When I use dspel:include within a custom tag like below things work fine.

<betweengo:link href="/click.do?id=foo"><dspel:include
page="/include/bar.jsp"/></betweengo:link>

However when I add flush=”true” it fails silently.

<betweengo:link href="/click.do?id=foo"><dspel:include
page="/include/bar.jsp" flush="true"/></betweengo:link>

The JSP page no longer renders after it gets to this line of code.  What puzzles me even more is that the documentation says that if you do not explicitly set flush, flush happens automatically.  Therefore theoretically adding flush=”true” should not have an effect though I do it because the documentation recommends doing it.

The above code is happening within a TargetingForEach droplet.  It is running on an ATG 2006.3 Patch 2 app server with JBoss 4.0.4.GA.

I contacted ATG support about this issue and they responded very quickly.  Basically they said don’t use flush=”true” on third party application servers and just rely on the automatic flush.

Entered on 07/29/2008 at 13:12:19 by Nicholas Glover:
Hi Frank,

You should note that JBoss 4.0.4 GA is not supported with any version of ATG and you should not be using it. Please stick with JBoss 4.0.3 SP1.

Also, it is imperative that you upgrade from your ATG version to the latest 2006.3 patch, patch 6. The latest patch has many bugfixes include a fix for one relating to flushing behavior, PR #134387.

Due to various bugs and issues encountered, use of the “flush” attribute with a 3rd party app server, is not really recommended. We are removing all docs for this feature in later versions of our documentation. In this case, flush=true is forcing an explicit flush on the current page; but if this is not set, a more “intelligent” auto flush is done that flushes top-level pages first and then progresses down the tree. This prevents problems with 3rd party app servers such as content getting rendered out of order. I recommend not messing with the “flush” setting.

Is there something you are trying to do that is not working that leads you to want to use the “flush” attribute?

Thanks.

—
Nick Glover
ATG Support

Entered on 07/29/2008 at 15:02:57 by Nicholas Glover:
Hi Frank,

I had already entered the documentation bug about this previously, but I polished and published it for our site with what I learned when looking into this for a prior customer and when looking into it for you.

It is PR #146637. Here’s the link:
http://www.atg.com/esupport/bugs/index.jsp?FullViewBug=ViewBug&bugId=146637

I’ll close this case now.

Thanks.

—
Nick Glover
ATG Support

Enabling Trace Level Debugging in JBoss

Posted on by
Reply

In JBoss 4.0.4.GA it took me awhile to figure out how to enable trace level debugging.

Typically you could do something like this to enable trace level debugging for a category of classes.

<category  name="com.betweengo.app">
  <priority  value="TRACE"/>
</category>

However JBoss 4.0.4.GA has an older log4j implementation so you need to use JBoss’s custom TRACE level.

<category  name="com.betweengo.app">
  <priority  value="TRACE" class="org.jboss.logging.XLevel"/>
</category>

This is documented in the release notes for JBoss-4.2.1.GA.

Since the latest log4j includes a trace level, there is no need to reference the custom jboss TRACE level in conf/jboss-log4j.xml configs, JBAS-4163.

There is additional information on trace level debugging in the articles Enabling TRACE logging on server and Using Logging.

Log SQL on ATG

Posted on by
Reply

Dudley Zoo Sarah the Sumatran Tiger (Life Of Pi) on FlickrDudley Zoo Sarah the Sumatran Tiger (Life Of Pi) by donebythehandsofabrokenartist

To log SQL turn on logging debug for your Repository component.

For example, set /betweengo/repository/Repository.loggingDebug to true.

Note that a lot of SQL statements are outputted. If you want to selectively turn it on and off you can put this in your JSP where you want to start logging SQL.

<dspel:setvalue bean="/betweengo/repository/Repository.loggingDebug"  value="true"/>

And then put this in your JSP where you want to stop logging SQL.

<dspel:setvalue bean="/betweengo/repository/Repository.loggingDebug"  value="false"/>

Note I think this solution only works if you are using a javax.sql.DataSource like in a JBoss configuration.

For ATG’s atg.service.jdbc.FakeXADataSource there are special properties for logging SQL.

Property Description
loggingSQLError logs SQL exceptions as errors
loggingSQLWarning logs SQL warnings received by the pool
loggingSQLInfo logs SQL statements sent by the pool
loggingSQLDebug logs JDBC method calls made by the pool

For debugging purposes most of the time you will just want to set loggingSQLInfo=true.

For further reading please see Configuring ATG Data Sources for Data Import in the ATG Installation and Configuration Guide.

How to Log SQL on JBoss

Posted on by
1

Edit the log4j.xml in the conf directory as shown below to turn on SQL debugging of the JDBC CMP plugin.

/apps/jboss/server/default/conf :->diff -c log4j.xml~ log4j.xml
*** log4j.xml~  Mon Sep 30 18:09:27 2002
--- log4j.xml   Tue Apr  4 20:41:18 2006
***************
*** 61,73 ****
    <!-- ============================== -->

    <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
!     <param name="Threshold" value="INFO"/>
      <param name="Target" value="System.out"/>

      <layout class="org.apache.log4j.PatternLayout">
        <!-- The default pattern: Date Priority [Category] Message\\n -->
        <param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>

      </layout>
    </appender>

--- 61,79 ----
    <!-- ============================== -->

    <appender name="CONSOLE" class="org.apache.log4j.ConsoleAppender">
!     <!--<param name="Threshold" value="INFO"/>-->
!     <param name="Threshold" value="DEBUG"/>
      <param name="Target" value="System.out"/>

      <layout class="org.apache.log4j.PatternLayout">
        <!-- The default pattern: Date Priority [Category] Message\\n -->
        <param name="ConversionPattern" value="%d{ABSOLUTE} %-5p [%c{1}] %m%n"/>

      </layout>
+
+     <category name="org.jboss.ejb.plugins.cmp.jdbc">
+       <priority value="DEBUG"/>
+     </category>
+
    </appender>

If you want to log Hibernate SQL statements:

    <category name="org.hibernate.SQL">
      <priority value="DEBUG"/>
    </category>

If you want to log everything Hibernate’s doing, including SQL statements, schema export, transactions, etc.:

    <category name="org.hibernate.SQL">
      <priority value="DEBUG"/>
    </category>