Hey all,

It's been some time... lol (been super busy lately)

Been looking around for a way to toggle what shows within a drill-down URL after it loads from its parent report so it doesn't showcase servers and report parameters.

Do any of you know of a simple way to secure the URL links for drill-downs in WF? Is there an admin setting somewhere? Or something I can code into each procedure maybe? (rather have a global toggle)

Any help/insights are much appreciated!

Thanks in advance!

UPDATE: So, are we still sitting at the point where the only way to ensure we can use the HTTP POST method is to code it into each and every one of our procedures through a Js function call and custom form submission at the bottom? You think this would be a simple SET HTTPMETHOD = POST or something.... Oi... Whatever. Will work with this solution unless any of you know more on if any progress has been made over the past near 10 years since the 3 posts I've found below talk of this subject:

Post 1

Post 2

Post 3

This message has been edited. Last edited by: <Emily McAllister>,

I use a JavaScript function to create a form tag dynamically on the page, and then throw everything into the submission cookie instead of on the url line. It lets me send huge amounts of data and encrypts the contents on https connections. Set your report drill-downs for JavaScript and wrap your output in an html page to get access to it.

But -- that's only hiding the parameters from people sniffing the package in-transit. An end-user can pull apart the web page to see its contents if they're so inclined. Are you running a named-user connection? Is your issue regarding your named users or outside intruders?

Hey John,

We are secured through Active Directory (named-user) connections at our site. We basically want/need a way to hide the parameters being passed to any drill down reports/graphs so they do not show up in the URL address bar once drilled to. Whether this be our named-users or from the outside world. Ideally they wouldn't be able to even see the file or app path either. Testing out the others' code on the above links doesn't seem to work too well. When you get a free moment or two, would you be willing to create a CAR file example of what you are telling works for you at your site? I would greatly appreciate the help and insight.

Thanks!

This is an example of what you're doing --

 

  var form=document.createElement("form");
  form.method="post";
  form.name="form";
  document.body.appendChild(form);
  form.innerHTML="<INPUT TYPE='hidden' NAME='IBIF_cmd' VALUE='MNTCON RUN Encounter_Record_Editor'>"
                +"<INPUT TYPE='hidden' NAME='IBIS_passthru' VALUE='on'>"
                +"<INPUT TYPE='hidden' NAME='IBIS_connect' VALUE='on'>"
                +"<INPUT TYPE='hidden' NAME='IBIAPP_app' VALUE='aidsmaintain'>"
                +"<INPUT TYPE='hidden' NAME='IBIC_server' VALUE='MAINTAIN'>"
                +"<INPUT TYPE='hidden' NAME='RandomNum' VALUE=" + getRandomNumber + ">"
  form.submit();

 

Line 1 dynamically creates a new form object. It's not connected to anything yet, but it's available for use.
Line 2 sets the forms method to POST so that its payload travels in the cookie instead of on the url line.
Line 3 gives the object a name. Call it what you like.
Line 4 attached the form to your current page. You don't see it because it's empty, and the stuff you'll add is hidden. But it's there.
Line 5 is lining up the variables you need to execute a WebFOCUS request from the form. App, server, etc., this particular example is calling WebFOCUS Maintain, I think you'll want "/ibi_apps/WFServlet?IBIF_webapp=ibi_apps" for you IBIF_cmd variable. String together all the submission variables you need, and I always put a random number on the end to make sure the browser doesn't return a cached version of the page. I hate caching. Hate it.
Line 11 submits the request. You're done.

Drop this into a JavaScript function and let it rip.

You likely should remove it (document.body.removeElement maybe?) when you're done if this is attached to a tabular report. That way you don't have dozens of them piling on top of the same name when the user clicks multiple rows. This one was a one-off for me, when the user clicks the page is done.

So, for use with just a simple report from the Content repository area, it would go something like this?:

TABLE FILE CAR
PRINT SALES
BY COUNTRY
BY MODEL
ON TABLE PCHOLD FORMAT HTML
ON TABLE SET PAGE NOLEAD
ON TABLE SET STYLESHEET *
TYPE=REPORT, GRID=OFF, FONT='VERDANA', SIZE=8, $
TYPE=TITLE, STYLE=BOLD, $
TYPE=DATA, COLUMN=COUNTRY, JAVASCRIPT=DrillTo( COUNTRY ), $
ENDSTYLE
END
-RUN

-HTMLFORM BEGIN
<script>
function DrillTo(vCountry) {
  var form=document.createElement("form");
  form.method="post";
  form.name="form";
  document.body.appendChild(form);
  form.innerHTML="<INPUT TYPE='hidden' NAME='IBIC_server' VALUE='slcbizprod'>"
                +"<INPUT TYPE='hidden' NAME='IBIF_cmd' VALUE='/ibi_apps/WFServlet.ibfs'>"
                +"<INPUT TYPE='hidden' NAME='IBFS1_action' VALUE='RUNFEX'>"
                +"<INPUT TYPE='hidden' NAME='IBFS_path' VALUE='/WFC/Repository/domainFolder/subFolder/car_drill.fex'>"
	        +"<INPUT TYPE='hidden' NAME='COUNTRY' VALUE='vCountry'>"
                +"<INPUT TYPE='hidden' NAME='RandomNum' VALUE=" + getRandomNumber + ">"
  form.submit();
}
-HTMLFORM END

I can't get the drills to work with the above code. I took out the input elements I thought weren't needed, and based it off of the following drill down URL generated from another report we run from time to time. (Of course I've modified it to give generic indications of server names, etc.)

"http://serverName/ibi_apps/WFServlet.ibfs?IBFS1_action=RUNFEX&IBFS_path=/WFC/Repository/domainFolder/.../drillReport.fex"

Is there a listing of all the various variables that need passing somewhere you think? Or do you know off-hand? Anyone? haha

Thanks for your insights and code example so far John. Really appreciate your time.

I'd put IBFS1_action=RUNFEX back in. There are other forum entries on this for the wfservlet call. I'll see if I can find them. They were for Version 7 though.

Switch it to a GET for the moment to see what you're assembling on the url. You may have an additional / that you don't need or something niggly like that.

And you know, it's different if you're calling an MRE report than if you're calling a apps directory report.

This message has been edited. Last edited by: John_Edwards,

The IBFS1_action=RUNFEX is in there. Were your thinking about another one? Sounds good. I'm looking myself. I click the parent report links and get nothing. If I try to open in a new tab, I get about:blank. Thanks for your help!

quote:

...So, for use with just a simple report from the Content repository area, it would go something like this?:...

Just looking at your code I'd say you are almost there...

I think your HOLD command would be HOLD not PCHOLD; you'd give the HOLD file a name too.

Then in the presentation section (-HTMLFORM) you'd want to have a !IBI.FIL.holdfilename; command.

See the 'Linking to a JavaScript Function', in the 'Creating Reports with WebFOCUS Language' manual for this design pattern.

This message has been edited. Last edited by: David Briars,