Subscribe by Email
Internet Explorer Address Bar and Siebel Browser Script
By neel | May 19, 2008
An IE address bar in Siebel can be used for more than just showing the current web address or the current URL. This tip or piece of info was recently discovered by a colleague of mine Tejeshwer Anand. Below are the instructions on how to use it.
- Open your Siebel Application Client (Thin or Dedicated)
- Just go the address bar as shown in the picture below.
- Type the following code in the Address Bar as shown in the picture
javascript:alert(theApplication().GetProfileAttr("Me.First Name"));
- Hit Enter Key
- It will return you the First Name of the person logged it.
I guess now you know what I am trying to say.Using this technique you can do whatever is possible through browser scripts. The reason being browser scripts are nothing but JavaScript code and a corresponding JS file is generated for the object on which you write the browser script. So you can directly write the browser script code in the address bar after JavaScript prompt and it will do just like it does in broswer script.
You can even call a business service through this technique provided your CFG contains the entry for that BS.
For example you can write.
javascript:alert(var bo = theApplication().ActiveBusObject(););
This will return you the active bus object and assign it to variable ‘bo’.
This can be real handy if you want to check, weather a particular Profile Attribute has been successfully SET or NOT or in case you want to SET 
a particular Profile Attribute.
To set a particular Profile Attribute you can write
javascript:alert(theApplication().SetProfileAttr("Test",”TestValue”));
Enjoy 
(12 votes, average: 4.58 out of 5)
Loading ...Related Posts
Categories: How - To |
May 19th, 2008 at 11:14 am
I have been using this for quite a while now. It is a real cool way of working especially with profile attributes when u need to simulate a business service and a profile attribute is not which would have been in a normally UI Navigation or a workflow.
One small tip always put the alert after javascript to avoid the Siebel Page being offloaded.
You can call javascript:theApplication().SetProfileAttr(”Test”,”TestValue”);
But This will write the return value to the body which is the siebel webpagecontainer.
Also always use theApplication() TheApplication() doesn’t work as TheApplication() is not defined as a top level object by Siebel in their JS framework.
May 20th, 2008 at 12:27 am
[...] Top tip today from Neel over at Siebel Unleashed: using the IE address bar to enter browser script. [...]
May 21st, 2008 at 3:11 pm
I am very impressed! This is something I hadn’t thought to do! Now my mind is racing with the possibilities, and whether I have to worry about any vulnerabilities in Siebel because of this. Thank you.
I know I will use this.
May 21st, 2008 at 10:45 pm
You need not really worry about any vulnerabilities.
All the code that you have access by this way is what you intend to be sent to the end user. Any Operation on applet or BusComp is allowed if it allowed to be done on the active instance on the browser side.
Consider this scenario that i implemented in one of the projects. Say you have customized the delete button by disabling the DeleteRecord button. You have a new button which is enabled and the method for that is CustomDeleteRecord.
On a call of this it would throw a custom message to the user rather than the vanilla warning message and if user clicks on OK It goes to server script and on the server script of this button there is a code this.InvokeMethod(”DeleteRecord”);
Now the only way to delete a record on the applet thru UI or browser scripting is to press the custom button or use this.InvokeMethod(”CustomDeleteRecord”) as the DeleteRecord has been set to CanInvoke to true.
Basically the main use of CanInvoke is to enable a method to be executed from the browser side or not. Hence a clever user can still not call javascript:alert(theApplication().FindApplet(”…”).InvokeMethod(”DeleteRecord”));
This would not execute the method as CanInvoke is set to FALSE
while the following line would be executed perfectly.
javascript:alert(theApplication().FindApplet(”…”).InvokeMethod(”CustomDeleteRecord”));
Consider a second scenario that is of calling a business service from a browser script.
Imagine if all the business services were available to be run for execution from browser side. There is a possibility that Siebel could be really vulnerable and myself as a developer would never need the help of my administrator. Hence Siebel wants to load the business service that the developer wants to use thru browser script. and hence only those with a cfg entry or application entry from 8.0 onwards are allowed too be called thru browser script. I had come across one post on this site to have a workaround to avoid cfg entry and always call any business service thru a custom business service. this is not a clever way of development as you may not be the only one who is developing and there maybe many others and there could be one with crooked thoughts to misuse it. Hence all business services to be run thru browser script are needed to have a cfg entry and there are normally assumed to be approved by your chief designer or the admin so that you don’t end up adding unwanted BS to this list.
In either case if a code that is not intended to be executed is available for execution thru this method is completly the fault of the developer and the vulnerability is put by that person or not siebel.
Say you have written a good piece of code for the method on the server side for a button called DeleteLOVs on some applet and enabled the method by using CanInoke to true. One the server side method for this written a code to delete some list of values using a BC on the S_LST_OF_VAL without No Delete. Now since the CanInvoke is TRUE even if the button is not present on the applet. Just go a view on which this applet is present and execute the following code thru address bar
javascript:alert(theApplication().FindApplet(”…”).InvokeMethod(”DeleteLOVs”));
This would delete all the LOVs that you wanted to thru the script. This is just a malicious code put in by the developer.
So it is the developer who calls the shots how to run the application and not Siebel itself though Siebel executes all the logic
June 23rd, 2008 at 7:27 am
Neel,
Really very good information.
I must say wonderful
This can be used for Debugging too.