Integration and security

[Migrated From Jforum.net]

Hi,
I would like to know for the security (relation in the database) of the forum because I would like to integrate this beautiful forum in a Portail. The Portail have already a database with Oracle. so i would like to interface the 2 database.
thank you for your help.
luc
[originally posted on jforum.net by Anonymous]

[Migrated From Jforum.net]

The JForum code uses a datamodel for all data.

If you look in the package "", you will see all of the code related to storing and retrieving data.

Modifying to work with Oracle is not a dead simple port. First, you need to install the Oracle JDBC driver. Next, you have to change the JForum JDBC URL to point to your Oracle database and the new driver.

However, that is the easy part. The real issue is going to be JForum's use of the MySQL TEXT datatype. Oracle has no such datatype. In fact, Oracle can only handle text of VARCHAR(255). I have run into this problem with EVERY Oracle port, and it sucks. The fact that Oracle has never included a TEXT datatype tells me that their DB design is too rigid to accomodate it (not a good sign).

This is why, in every DB design I have done, I put all TEXT field into completely separate tables and reference them from the real records. This was I can accomodate Oracle (and other DBs) more easily.

In the case of JForum, that will not be the case (the TEXT fields are inline with the records). So, you will need to find a special Oracle field that can accomodate text of length more than 255. I forget what was used in the past, but I believe there is a binary datatype that you can use.

The bottom line: more than 15 minutes of work!

[originally posted on jforum.net by time]

[Migrated From Jforum.net]

You can use Blob in the place of Text, afaik.

Rafael
[originally posted on jforum.net by Rafael Steil]

[Migrated From Jforum.net]

There where a bunch of mods done to BugRat, the bug reporting system written for the Giant Java Tree (www.gjt.org). You can download the complete BugRat source at http://www.gjt.org/pkg/bugrat/.

The few mods that I saw from an initial scan of the code follow. First, it appears that Oracle does not distinguish between an empty string ("") and a string that is NULL. BugRat had used NULL strings to indicate that a category level was "unset", but had to be updated to use "." instead:

	
        /**
	 * Large string support.
	 * 
	 * Some database products (Oracle) can not handle
	 * strings larger than 4000 bytes. Wow. So, to better
	 * support these products, we have defined this special
	 * method in the event that the developer needs to hack
	 * in support for their special database.
	 *
	 * In the default case, this simply calls through to the
	 * getString() method.
	 *
	 * Oracle database developers have been accomodated
	 * here with code that may or may not work. Since I would
	 * never choose Oracle as a database, I am not able to
	 * test this code. However, if someone is willing to make
	 * sure the code works and send me the patches, I will make
	 * sure they are applied. Note that you must set the servlet
	 * initial parameter to get this code to select "usingOracle".
	 *
	 * See web.xml for more details.
	 *
	 * Other database users are also free to send patches.
	 *
	 * NOTE: Hacks that require JDBC 2.0 are not likely to make
	 *       direct release, as I do not want to tie BugRat to
	 *       that API just yet. However, they will be included
	 *       as comments (like the Clobs below) for those who
	 *       need them.
	 *
	 */

	public String
	getLargeString( ResultSet rs, int col )
		throws SQLException
		{
		if ( ! this.handler.isUsingOracle() )
			return this.getString( rs, col );

		InputStream is = rs.getAsciiStream( col );
		if ( is == null )
			return "";

		StringBuffer strBuf = new StringBuffer();
		try {
			for ( byte[] byteBuf = new byte[1024] ; ; )
				{
				int numRead = is.read( byteBuf );
				if ( numRead == -1 )
					break;
				strBuf.append( new String( byteBuf, 0, numRead ) );
				}
			}
		catch ( IOException ex )
			{
			throw new SQLException
				( "IOException reading large string, " + ex.getMessage() );
			}
		finally
			{
			try { is.close(); }
				catch ( IOException ex ) {}
			}

		return strBuf.toString();
		}

	/**
	 * Large string support.
	 * 
	 * Some utterly lame database products can not handle
	 * strings larger than 4000 bytes. Wow. So, to better
	 * support these products, we have defined this special
	 * method in the event that the developer needs to hack
	 * in support for their special database.
	 *
	 * In the default case, this simply calls through to the
	 * setNullString() method.
	 *
	 * Oracle (aka lame database) users have been accomodated
	 * here with code that may or may not work. Since I would
	 * never choose Oracle as a database, I am not able to
	 * test this code. However, if someone is willing to make
	 * sure the code works and send me the patches, I will make
	 * sure they are applied. Note that you must set the servlet
	 * initial parameter to get this code to select "usingOracle".
	 *
	 * See web.xml for more details.
	 *
	 * Other database users are also free to send patches.
	 *
	 * NOTE: Hacks that require JDBC 2.0 are not likely to make
	 *       direct release, as I do not want to tie BugRat to
	 *       that API just yet. However, they will be included
	 *       as comments (like the Clobs below) for those who
	 *       need them.
	 *
	 */

	public void
	setLargeString( PreparedStatement pS, int col, String val, int sqlType )
		throws SQLException
		{
		if ( ! this.handler.isUsingOracle() )
			this.setNullString( pS, col, val, sqlType );

		if ( val == null )
			{
			pS.setNull( col, java.sql.Types.LONGVARCHAR );
			}
		else
			{
			ByteArrayInputStream baIn =
				new ByteArrayInputStream( val.getBytes() );
			pS.setAsciiStream( col, baIn, baIn.available() );
			}
		}

	/**
	 * FOR ORACLE USERS
	 *
	 * This method retrieves a Character Large Object (CLOB) from the
	 * database. This is used where the MySQL "mediumblob" can not.
	 *
	 * This is used for description.desctext, properties.propval,
	 * emailcontent.content, and envdesc.envdesc.
	 *
	 * DO NOT CALL THIS DIRECT. Call it via getLargeString() and
	 * set the oracle servlet parameter.
	 *
	 * @param rs The ResultSet having the proper row in its cursor.
	 * @param col The Column-counter of the field which has the CLOB.
	 * @returns a java.lang.String that contains the whole CLOB.
	 */

	/* ***
	public String
	getClob( ResultSet rs, int col )
		throws SQLException
		{
		java.sql.Clob clob = ((OracleResultSet) rs).getClob( col );
		char[] cdata = new char[ (int)clob.length() ];
		Reader cs = clob.getCharacterStream();

		try {
			cs.read( cdata );
			}
		catch ( IOException ex )
			{
			throw new SQLException
				( "reading CLOB field - " + ex.getMessage() );
			}

		return new String( cdata );
		}
	 * ***/

	/**
	 * FOR ORACLE USERS - UNDONE
	 *
	 * This method set a Character Large Object (CLOB) in the
	 * database. This is used where the MySQL "mediumblob" can not.
	 *
	 * This is used for description.desctext, properties.propval,
	 * emailcontent.content, and envdesc.envdesc.
	 *
	 * It appears that you must select to get the clobs, then modify
	 * the CLOB which in turn modifies the database?!?! Wow!
	 *
	 * DO NOT CALL THIS DIRECT. Call it via setLargeString() and
	 * set the oracle servlet parameter.
	 *
	 * @param rs The ResultSet having the proper row in its cursor.
	 * @param col The Column-counter of the field which has the CLOB.
	 * @returns a java.lang.String that contains the whole CLOB.
	 */

	/* ***
	public void
	setClob( PreparedStatement pS, int col, String value )
		throws SQLException
		{
		// UNDONE
		// UNDONE
		}
	 * ***/

I realize it is not that complete, but I hope it helps.

[originally posted on jforum.net by Anonymous]

[Migrated From Jforum.net]

That last post was from me.

I think it points out a bug. I was posting that comment for some long period of time. I was logged in as myself. However, I think the session timed out while I was editting the post, and so when I posted it, I became anonymous.
[originally posted on jforum.net by time]

[Migrated From Jforum.net]

time wrote:That last post was from me.

I think it points out a bug. I was posting that comment for some long period of time. I was logged in as myself. However, I think the session timed out while I was editting the post, and so when I posted it, I became anonymous.

If you don't check "Log me on automatically", then yes, the container will invalidate your session after a long period of inactivity ( 30 minutes ) and you get an anonymous user id. If you'd checked to log in automatically, the system would ensure you don't loose your id.

Rafael
[originally posted on jforum.net by Rafael Steil]