Recently I have seen an issue in 11.1.2.4 with simplified forms where SSL is being either terminated at the load balancer or OHS.
If you are on 11.1.2.4 and are not using any flavour SSL or have implemented full SSL then you will not come across this problem.
As the simplified interface is the way forward for planning and over time the standard interface will disappear then there is a possibility you may run into this issue so I thought I would write it up.
So let me go through an example of the problem first where SSL is being terminated at OHS, so basically you will be accessing planning over https via OHS and then OHS proxies to the planning WebLogic managed server over http.
You should not see any issues with functionality until you try to use a simplified form.
In the above example I have autosave enabled in the form settings though it is exactly the same if you click the save button, at first it looks like after entering data the data is saved but if you refresh you will notice that it has not.
Also if you try to expand or collapse members then nothing will happen.
After delving into this issue a little you start to unravel what is happening.
When saving a form or data in a cell planning attempts to post the data back to a planning servlet but as you can see it is trying to post the data back over http and not https.
Tracing the issue further you can locate the JavaScript function where the post is happening.
The script is using XMLHttpRequest which provides client side functionality for transferring data between a client and a server without having to a full page refresh so speeds up data entry in a form.
The culprit here is the URL held in the variable "enterDataServlet" which is used in many of the JavaScript functions in a simplified form.
The URL is using http instead of https and it is possible to track down how the URL is generated in a JavaServer Page (JSP)
The Java method getScheme() returns whether the request was made over http or https, this method is well known to cause issues when SSL is being offloaded because the request to planning is being proxied over http so that is what is being returned instead of https.
As the post if being sent back over http instead of https it fails and no data is submitted.
Luckily when SSL is being terminated at OHS there is a quick and simple fix to overcome this issue.
Fire up the WebLogic admin server and log into the admin console, for each managed server there is a configuration setting called "WebLogic Plugin-Enabled"
By default this setting is not enabled, once enabled it changes the way the header information is handled through the web server plug-in and the proxied request from OHS should be returned as https instead of http.
After making the change and restarting planning it will be possible to submit data in a simplified form.
Refresh form after saving.
This time in the JavaScript code https is being correctly generated for the URL.
If SSL is being terminated at the load balancer then there is more to it than just enabling the WebLogic Plug-In setting.
The flow now will be:
Load Balancer (https) > OHS (http) > WebLogic (http)
Here is the same example when SSL is being terminated at the load balancer and the "WebLogic Plug-In" setting has been enabled.
Refresh form after saving.
The same issue that the data is not being submitted and looking at the script confirms it is using http instead of https.
Also as the load balancer is using the default https port the URL that is being generated is now set as port 80.
To resolve this issue we need to be able to proxy the SSL information from the load balancer to OHS and then to WebLogic.
The first step to do this is to add a request header to the load balancer configuration
If you are using an F5 load balancer then you can read how to add the header here
The problem now is that OHS will remove the header information that is being sent from the load balancer so it will not reach WebLogic and the same issue will occur.
To get around this there is a parameter available in the OHS WebLogic Plug-In configuration file called WLProxySSLPassThrough which by default is set to OFF.
This can be set globally or as I am doing setting it only for Planning.
Time to test again.
Refresh form after saving.
Good news the data is being submitted back to planning correctly.
In the JavaScript code the URL is being correctly formed using https and 443 as the port.
If you ever hit this problem in the future now you know the solution to fix it.
If you are on 11.1.2.4 and are not using any flavour SSL or have implemented full SSL then you will not come across this problem.
As the simplified interface is the way forward for planning and over time the standard interface will disappear then there is a possibility you may run into this issue so I thought I would write it up.
So let me go through an example of the problem first where SSL is being terminated at OHS, so basically you will be accessing planning over https via OHS and then OHS proxies to the planning WebLogic managed server over http.
You should not see any issues with functionality until you try to use a simplified form.
In the above example I have autosave enabled in the form settings though it is exactly the same if you click the save button, at first it looks like after entering data the data is saved but if you refresh you will notice that it has not.
Also if you try to expand or collapse members then nothing will happen.
After delving into this issue a little you start to unravel what is happening.
When saving a form or data in a cell planning attempts to post the data back to a planning servlet but as you can see it is trying to post the data back over http and not https.
Tracing the issue further you can locate the JavaScript function where the post is happening.
The script is using XMLHttpRequest which provides client side functionality for transferring data between a client and a server without having to a full page refresh so speeds up data entry in a form.
The culprit here is the URL held in the variable "enterDataServlet" which is used in many of the JavaScript functions in a simplified form.
The URL is using http instead of https and it is possible to track down how the URL is generated in a JavaServer Page (JSP)
The Java method getScheme() returns whether the request was made over http or https, this method is well known to cause issues when SSL is being offloaded because the request to planning is being proxied over http so that is what is being returned instead of https.
As the post if being sent back over http instead of https it fails and no data is submitted.
Luckily when SSL is being terminated at OHS there is a quick and simple fix to overcome this issue.
Fire up the WebLogic admin server and log into the admin console, for each managed server there is a configuration setting called "WebLogic Plugin-Enabled"
By default this setting is not enabled, once enabled it changes the way the header information is handled through the web server plug-in and the proxied request from OHS should be returned as https instead of http.
After making the change and restarting planning it will be possible to submit data in a simplified form.
Refresh form after saving.
This time in the JavaScript code https is being correctly generated for the URL.
If SSL is being terminated at the load balancer then there is more to it than just enabling the WebLogic Plug-In setting.
The flow now will be:
Load Balancer (https) > OHS (http) > WebLogic (http)
Here is the same example when SSL is being terminated at the load balancer and the "WebLogic Plug-In" setting has been enabled.
Refresh form after saving.
The same issue that the data is not being submitted and looking at the script confirms it is using http instead of https.
Also as the load balancer is using the default https port the URL that is being generated is now set as port 80.
To resolve this issue we need to be able to proxy the SSL information from the load balancer to OHS and then to WebLogic.
The first step to do this is to add a request header to the load balancer configuration
If you are using an F5 load balancer then you can read how to add the header here
The problem now is that OHS will remove the header information that is being sent from the load balancer so it will not reach WebLogic and the same issue will occur.
To get around this there is a parameter available in the OHS WebLogic Plug-In configuration file called WLProxySSLPassThrough which by default is set to OFF.
This can be set globally or as I am doing setting it only for Planning.
Time to test again.
Refresh form after saving.
Good news the data is being submitted back to planning correctly.
In the JavaScript code the URL is being correctly formed using https and 443 as the port.
If you ever hit this problem in the future now you know the solution to fix it.
On Planning 11.1.2.4.xx classic interface, there is a similar issue with the member formula editor calling Calc Manager editor through http and not https. Enabling weblogic plugin is also solving this issue.
ReplyDeleteThanks for this post!
ReplyDelete