Extending/Overwritting Browser Scripts capabilities

Hi, folks!

At some point of a project (in one of our clients), Oracle told us that when upgrading Siebel from 8.1.1.10 version to 8.1.1.11+, the SetProfileAttr method would stop working (because of a security flaw), and that we should replace all function calls by a custom Business Service that does the job. There is a System Preference that makes it works as before, but this System Preference is temporary, and should stop working on later versions. The main idea here, is that on a custom Business Service we can implement some restrictions on using this kind of method.

Scenario

On version upgrade projects, we have no control on what’s already there. And when upgrade involves deprecation of anything, these things invariably stop working. In this case, it is known that the upgrade to 8.1.1.11+ demands this kind of work.

Problem

Methods like SetProfileAttr shoudn’t be used on client-side anymore, as user can execute arbitrary Javascript code on their browser, that can crack the expected behavior of the application, as Profile Attributes are usually used to control some behavioral aspects.

Solution

Our first approach was to override GetProfileAttr and SetProfileAttr methods, directly in the theApplication() context. It could prevent us from changing all legacy browser scripts, and still have these methods calling a custom Business Service. But… no. Oracle told us that we could be causing impact on vanilla code.

So, our next step (still trying to do the right thing, but working less) was to have the same approach, but without overriding anything. Keeping it in mind, we had implemented GetProfileAttribute and SetProfileAttribute methods (you can see the difference, right?!). See below:

Tools_cropped

For a copy/paste purpose:

(declarations):

top.JSSApplicationShadow.prototype.GetServerProfileAttr = GetProfileAttribute;
top.JSSApplicationShadow.prototype.SetServerProfileAttr = SetProfileAttribute;

GetProfileAttribute(…):

function GetProfileAttribute(profAttrName) {
 var bs;
 var inPS;
 var outPS;
 var profAttrValue = "";

 try {
 bs = theApplication().GetService("SessionAccessService");

 inPS = theApplication().NewPropertySet();
 inPS.SetProperty("Name", profAttrName);

 outPS = bs.InvokeMethod("GetProfileAttr", inPS);
 profAttrValue = outPS.GetProperty("Value");
 } catch(e) {
 // nothing
 } finally {
 bs = null;
 inPS = null;
 outPS = null;
 }

 return profAttrValue;
}

SetProfileAttribute(…):

function SetProfileAttribute(profAttrName, profAttrValue) {
 var bs;
 var inPS;

 try {
 bs = theApplication().GetService("SessionAccessService");
 inPS = theApplication().NewPropertySet();

 inPS.SetProperty("Name", profAttrName);
 inPS.SetProperty("Value", profAttrValue);

 bs.InvokeMethod("SetProfileAttr", inPS);
 } catch(e) {
 // nothing
 } finally {
 bs = null;
 inPS = null;
 }
}

How you can use it?! On any Browser Script, in theApplication() context, as follows:

theApplication().SetProfileAttribute("profileAttribute", "newValue");

And thus we just need to change legacy code from…

theApplication().SetProfileAttr("profileAttribute", "newValue");

… to…

theApplication().SetProfileAttribute("profileAttribute", "newValue");

That’s it! :)

My opinion

If there is a security flaw involved, so this kind os workaround shouldn’t be used, or used carefully. But this approach may be useful to make code reusable. I mean… LookupValue is called by InvokeMethod, so we can implement something like theApplication().LookupValue(…), for example. Prototyping methods could be useful “in the future”, i mean… when working with Open UI (and maintaining High Interactivity in parallel somehow). I’ll write about it soon.

Thats all, folks! :) See you later…

Deixe uma resposta

O seu endereço de email não será publicado Campos obrigatórios são marcados *

Você pode usar estas tags e atributos de HTML: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>