cancel
Showing results for 
Search instead for 
Did you mean: 

Custom.jsp issues

DellSC
Active Contributor
0 Kudos

I'm not sure whether to post this here or over in the BI Platform space...

I have a client who is upgrading from 3.1 to 4.0 SP8.  In 3.1 they have custom code for accessing InfoView and OpenDocument from their CRM application.  This code, which runs under Tomcat on the BO web server, takes in a Base64 encoded user ID, decodes it, and then passes it in a session variable to the InfoView login screen which is configured for SSO using Trusted Authentication.  The code is actually very simple - less than 20 lines.  I'm trying to use the custom.jsp files from both com.businessobjects.webpath.InfoView.jar and com.businessobjects.webpath.OpenDocument.jar as outlined in the OEM Customization Guide for handling this requirement.

The problem I'm running into is that the client is using commons-codec-1.4.jar to do the Base64 encoding.  This .jar file is not part of the standard library files that are part of BO.  I can't find where to put this so that it can be "seen" from custom.jsp.  For testing purposes, I've put it in the webapps\BOE\eclipse\plugins\webpath.InfoView\web\WEB-INF\lib folders under both tomcat and work\Catalina\localhost, but that didn't work.  I've also tried putting it in the lib folder under tomcat and in the same folder as custom.jsp, but still no luck.

Can anyone point me to where this .jar file needs to go so that I can get this process working?

Thanks!

-Dell

Accepted Solutions (1)

Accepted Solutions (1)

Former Member
0 Kudos

Hi Dell,

I did tests and the problem seems to be coming from the fact that another jar loaded from the webpath.infoview directory also has a Base64 class in it and is conflicting.

If I rename or remove the jsf-impl.jar file and re-start Tomcat, the custom.jsp runs without error, but there’s no knowing what part of BILaunchpad we broke by doing this so it is not a solution, but merely points out what the problem is.

You may have to find some other Base64 encoder and try using that jar rather than the commons-codec-1.4.jar as we have other areas of our application that uses commons-codec-1.3.jar and replacing this with the 1.4 version may also cause unknown problems.

Using a different library that does base64 encoding would help ensure that we do not change versions that are used in other parts of the product and would prevent possible overwriting of the jar.

If we change the version of an existing jar, then that becomes an unsupported scenario.

Made the following changes to your code and the page ran without errors, however we have no idea if the decryption would work properly as we don’t know if similar algorithms would be used, but its something you can look into:

<%@page import="com.sun.faces.util.*"%><html>

<head>
<meta http-equiv="Content-Type" content="text/html; charset=ISO-8859-1">
<title>CRM Authentication Check and Redirect</title>
</head>
<body>

<%
//String openURL = "https://busobjprod.namasco.net:8443/BOE/BI";
String openURL = "http://localhost:8080/BOE/BI";
String userid = request.getParameter("userid");

if (userid == null)
   {
    //If the expected header variable is missing we will redirect to the manual logon page.
    response.sendRedirect("/BOE/BI");
    }
else
    {
    // Decrypt the incoming values
    SecretKeySpec skeySpec = (SecretKeySpec) application.getAttribute("NAMASCOSECRET");
    if (skeySpec == null) {
        String secret64 = "xpgVbeA5q5tmvUq_qEbjxA";
                                byte[] test = secret64.getBytes();

        byte[] raw = com.sun.faces.util.Base64.decode(test);
        skeySpec = new SecretKeySpec(raw, "AES");
        application.setAttribute("NAMASCOSECRET",skeySpec);
    }
    Cipher cipher = Cipher.getInstance("AES");
    cipher.init(Cipher.DECRYPT_MODE, skeySpec);

    // convert incoming string to bytes
                byte[] test2 = userid.getBytes();
    String user = new String(cipher.doFinal(com.sun.faces.util.Base64.decode(test2)));


hope this helps

Let me know in case of any any queries.

Thanks,
Feroz

Answers (0)