Is there any way of using a WebFocus report to display the content of an existing PDF?

Background: We have a large number of PDF "report" documents sitting on a file server (not generated from WebFocus) that our WebFocus users also need to access. The long term plan is to utilize a document management system for this but in the interim we'd like to provide a means for these users to select and display the reports through the BID which is where they'll be getting all of their WebFocus reports.

Since we have access to the metadata that associates the PDF documents to the users we could envision using the HTML layout painter to build a prompt screen that allows users to choose available PDFs, however once they select a PDF we need to display it (presumably through a 'blank' WebFocus report).

We searched the forum but haven't much that was specifically related to this subject.
Any ideas out there?

Thanks in advance,
Michael Goshey

Michael, just a plain URL, an ordinary hyperlink to the pdfs on your server, would be simple enough to allow the users to access the various reports.
You could build a static page, full of these links, using ordinary html code, and call this launch page via webfocus with a filedef to that html lauch page.

FILDEF MYPAGE DISK \\servername\...\MYLAUNCHPAGE.HTML
-RUN
-HTMLFORM BEGIN
!IBI.FIL.MYPAGE;
-HTMLFORM END

Or...if the report names change... you could use focus to read a network directory with DOS commands, produce a list file, read that list file and extract the document names, and build an html launch page dynamically.
Any help?

Susannah: Thanks- you've given us several ideas and I believe we can get a nice solution from this.

Gratefully,
Michael

Not really a way to "display" the reports in BID per se, but as susannah suggests, a simple hyperlink to the report would allow users to select a report which would then be displayed with the Adobe Reader utility.

good clarification, Darin. thanks. and great to have met you at Summit.

Please forgive my tangental question on this subject, but I've been increasingly concerned about the security ramifications of FILEDEF and the OS CMD facility.

Is there any way to limit (jail) a person's access with FILDEF? Susannah, with your example it is trivially easy to point MYPAGE to any file on the system that the reporting server account has access to (like sensitive files such as /etc/passwd on Unix). It also seems trivially easy to overwrite files of the reporting server using FILEDEF MYPAGE then an ON TABLE SAVE AS MYPAGE, effectively trashing an installation. This would not be a concern in a trust model where a person with adhoc edit capability "acts responsibly". But there seems to be a lot of WebFOCUS installations with the default WF homepage.jsp facing the Internet -- and any knowlegable vandal can trash a WF server with the adhoc fex link using FILEDEF or -DOS.

I known OS CMDS can be disabled by OPSYSCMD=OFF setting, and the adhoc fex execution disabled through TM4608, but is there any way to limit the damage that can be done with filesystem read/write access through FILEDEF?

Sorry for the tangent, I really like !IBI.FIL.MYPAGE in combination with FILEDEF, but I can't shake the feeling that this is a security risk waiting to be exploited on default installations. It would sure be nice if one can limit the scope of directories that FILEDEF can gain access to, similar to a unix jail shell.


-- Dan

University of Nebraska at Omaha
WebFOCUS 7.1.6 Linux

This message has been edited. Last edited by: Dan Kenny,

quote:

sensitive files such as /etc/passwd on Unix

Wouldn't files like these have OS-level security on them, thus prohibiting read access via FILEDEF? Shouldn't it be the responsibility of the server "masters" to ensure that sensitive data is secure?

Dan, the MYPAGE here is only a launch page, a list of linkable PDF focs, so trashing it doesn't have much value; The pdf's themselves (the documents of value) can be on a server\dir where the user community only has read access, as established by the server admins and only the WF server or some other powers-that-be would have write access.
So, i'm not too worried, but its probably my naivete talking.

Francis,

The Unix /etc/passwd has to be world-read, shows account login information (not passwords), something that can be used to further attempt penetration on a computer. The point is that one should not allow access to the file system from the casual user on the internet, even if it's just an application user ID. FILEDEF provides an exposure point to the entire file system. Some of it can be constrained by file permissions. But much can't.

Susannah/Francis, perhaps this will demonstrate my concern.

Take the stock URL for the adhoc fex utility on 5.3.x or 7.x -- server/ibi_html/homepage/adhoc.htm (or just any fex that you or an analytical user with edit capability might run).

 
FILEDEF MYPAGE DISK \IBI\APPS\IBISAMP\CARGRAPH.FEX
-RUN
-HTMLFORM BEGIN
<PRE>
!IBI.FIL.MYPAGE;
</PRE>
-HTMLFORM END

The above code will display the source of the
CARGRAPH.FEX file. Consider that any FEX source code can be displayed through FILEDEF by knowing the file location, if one has adhoc execution capability.

Then consider this (after making a backup of CARGRAPH.FEX, of course):

  
FILEDEF MYPAGE DISK \IBI\APPS\IBISAMP\CARGRAPH.FEX
TABLE FILE CAR
PRINT COUNTRY
WHERE COUNTRY EQ 'NOWHERE';
ON TABLE SAVE AS MYPAGE
END

The Fex has just been trashed (truncated). This makes me nervous.

I understand the power and need for FILEDEF. I'd just like to limit the scope of filesystem traversal, i.e. put it in a Unix-style chroot "jail".

Again, sorry for the tangent. I should've started an independent thread.

Regards,

Dan

University of Nebraska at Omaha
WF 7.1.6 Linux

Has anybody come up with a 'safe' way to do this?

app lock is a way of restricting a user to files contained only within his APP PATH

http://documentation.informationbuilders.com/masterinde...pslang/apppath10.htm

FILEDEF is regarded as an APP command but is not listed in the list of restricted commands.

If it is not restricted then as you say there is a security hole that should be addressed.

I am sorry but I cant tell you if it is restricted or not since we not using APP LOCK but I would be interested to know what your results are.

Dan,

We have a large AIX self-service implementation with over 17,000 focexecs and have never had the condition where someone filedefs a focexec and trashes it.

We do do a variety of things with unix permissions. Since we have a number of business units, each one of those is in a separate group. We try to make sure that app directories for each user is assigned a group and owner and group have write permissions but world does not.

Hope this helps.

What about using the Report Library? I haven't even begun to play with ReportCaster so I don't even know if it can be done. It is possible to manually populate the Report Library with PDF files? If you could do that then the Report Library would serve as a repository of sorts for those existing PDF files.

Ginny

The wf server processes do not inherit O/S permissions from the requesting user but operate under the single permission of the user under which the server process trees lie.

Thus its impossible to have separate filesystem permissions for separate users without separate servers.

To say that something has never happened does not mean it is not possible.

We avoid Dan K's situation under W2003 by creating shares under windows with r/o access and only giving users access to those via APP PATH.

Again the userid under which the webfocus server process tree runs should only be given minimal rights necessary for wf and not admin rights etc otherwise it's possible to FILEDEF a vital system file and achieve the same result as Dan K has listed.

Preventing read access by FILEDEF is another matter where a hacker could gain access to vital info and that's why FILEDEF should be considered under the scope of APP LOCK.

Of course these concerns are much less if you are in a firewalled and relatively safe environment than if your system is open to the world.

quote:

The wf server processes do not inherit O/S permissions from the requesting user but operate under the single permission of the user under which the server process trees lie.

John, on Unix that is not true. We run with OPSYS security and a user cannot overwrite a file that is not owned by or in the same group as the user. Our developers get nailed by that a lot.

quote:

To say that something has never happened does not mean it is not possible.

And I definitely agree with that statement.