I was hoping to tap the knowledge of someone using this methododology. Am trying to get to the bottom of a problem but first let me establish the groundwork of identification here.

I am using a WF 5.3.2 installation on Windows XP. This is a standalone operation using Project-based development. No Managed Reporting, Dashboard, Report Caster, so things are fairly simple. My development work is on Developer Studio. Any and all other potential users are coming in via Self Serv apps, using IE on our government intranet.

I have followed all documentation that I know of including "WebFOCUS Self-Service Applications with IWA"

Basically things are successful, but with one annoying problem. As soon as a report is run (which in my case are mostly pdf or Excel) it seems that the WF Reporting server no longer recognizes who is there. This becomes evident when attempting to run a 2nd report.
Specifically, GETUSER becomes IUSR_machine_name instead of the individual's userid. Likewise of course &&USERID takes on this undesired and unwanted value. Code we have set up for security purposes routes the user to a rejection message.

This scenario I am describing does not happen to me in Dev Studio, only to the normal Self Serv app user in IE.

Now I have found that if the user returns to the original launch page that the session is reactivated somehow; GETUSER and &&USERID are appropriately refreshed and all is well until the next report is run.

Therefore I CAN adapt to this handicap, severely limiting myself to what would normally be constructed. Let me explain in some detail what WILL work for any who may be interested.

The launch page basically just has welcoming text and other gifs, etc. The only link is to another htmlform via a fex This is so the Reporting Server is called to establish identity. The html form is set up as a "_self" window. This second html form successfully displays &&USERNAME, although on the fex lead-in to the html form, had to install -SET &USERNAME = &&USERNAME since globals apparently cannot be made to display on forms at least not on 5.3.2.
!IBI.AMP.&USERID; does work.

On this second htmlform are links to html forms (not fexes) that contain a large number of &variable parameter settings for the pdf report run. These links are set up as _blank windows.

The 3rd htmlform then, also contains the link to run the report with its consequent call to the WF Reporting Server. The report is set to run to a _self window. When the report window is closed, it therefore closes itself along with the 3rd htmlform just described.

Returning in this way to the 2nd form, and continuing any executions from there WILL WORK; the server will continue to recognize the user no doubt because GETUSER continues to pass the correct value to &&USERNAME.

Now if I were to change so much as one simple element to all this, it results in failure. Let me give you one instance. Just suppose in the above scenario, and in the 3rd htmlform, and for the push button where we are calling the report-running fex, that we call for it to be run in a _blank window instead. Seems much more logical because then it would be quite easy to run a 2nd report. When the 1st report is killed, returning the user to the calling 3rd htmlform all is well....UNTIL that next report is attempted. This time when the WF Reporting Server is called, EDASERVE does not recognize us because GETUSER has gone bad. The latter has taken on the value of the machine name on which EDASERVE resides, namely my PC.

I have spent many hours (yes days) trying to research all this, tweaking settings, reading and re-reading documentation and trying to find the logic here which I am obviously missing.

I can assure you that I am not new to FOCUS. Have been using it since the mid 80's but must confess that WebFOCUS to me has been quite a challenge. Along the way I've heard that I confuse apples and oranges, but when lost in the woods they all blend in.

If my best solution is to upgrade to version 7, as all is well there, please tell me.

I'm wondering if your PDF/Excel reports are running in an IE shell, or in native PDF/Excel. If they are in native mode, WF loses the cookie info. You need to run the reports in an IE shell.

Here is what I do from Windows 2000 (hopefully XP is similar):
From the MS Explorer (right-click Start, then select Explore), select the menu item Tools, then the submenu item Folder Options....
From the Folder Options window, select the tab entitled File Types. A list of registered file types will appear.
From the Registered file types box, click on the XLS extension, then click the Advanced button.
The Edit File Type window opens. The New action should be highlighted.
The checkbox labeled Browse in same window needs to be checked. Then click OK.

This is my best guess.

Regards,
Sean

Hi Sean,
Thanks for this tip, and I did carefully check this out. I am going to say that in our environment here, Excel (when produced by WF) has not been opening in native Excel, even before checking out this setting. A "Save As" presents you with a default "Web Page" document where you must purposely change to "Excel Workbook" if you want the native environment.

I also tried to take your instruction to the pdf side, also selecting that but notice that "Browse in Same Window" is a grayed-out option there.

I have noticed (and don't know if this is true in all WF environments), that when I produce a pdf, that the back button will not return the user to the calling html form. When the form calls the report window to open as a _blank window ir cannot back-button to the form. If called as a _self window, then there's no need and can just X out.

I appreciate your help.
Bill

Bill,

Hmmm, I was hoping that was the issue. In my situation, when I would generate an Excel report in native mode, any amper variables that I had set using WF_SIGNON would be empty. And this was because the WF cookie that stored this info was lost when I left the IE window. But when I ran in an IE shell, the variables did not get lost.

Yes, the Back button in a PDF document will not return you to the calling window when opened with _blank. And I find even if you drill down to another PDF report from within a PDF report, you cannot use the Back button to get back to the original PDF, because temporary PDF files are created, which disappear when calling another PDF report.

Perhaps someone will be able to provide better insight.

Sean

Thanks again Sean. Any info is great. Now I know that its "normal" to not be able to back up from pdf back into the calling form.

Actually there seems to be a bit of a dearth on info for IWA. If I were up on the operation of the webserver, cgi and all that stuff I'm sure it would help. I have thought to myself though that this problem acts as though it is some kind of cookie loss. But how it comes back when you do certain things eludes me with my lack of knowledge in this area.

Appreciate the help.
Bill

Foccrawler,

Couple of things:
1) Globals in html !IBI.GLB.name;
2) By default, pdf's and excel files are actually generated on the server first, then a html document with an autopost is sent back to your browser. The autopost requests the saved pdf or excel file from the server. There is a javascript problem that MS refuses to fix that tries to replace the autopost html file in your browsers history, therefore, when you click back, you get the autopost which in turn recalls the pdf or excel. You can manipulate these things by changing WF's redirections (mime.wfs) for pdf and excel. Keep in mind, that there might be other issues you will have to contend with other then cannot backup. IBI decided to do redirects for collecting pdf's and excel files .... there is probably a good reason for it!

As far as your non-IWA stuff happening, remove the "Anonymous access" from your Directory Security for the ibi_cgi. If the users credentials are truely outside of pdf or excel's scope, then you should get a popup prompting your users for credentials. I don't believe it will have anything to do with a WF_Cookie, as that will not have any impact until after a connection to WF. "Not autorized" messages for invalid directory security access should only be coming from IIS, not WF. My guess is that the http requests coming from the plug-in to allow display of pdf and excel content is not being challenged by IIS, and therefore being allowed to enter as anonymous.

Give it a try and let us know what happens.

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

Dhagen,
Thank you. Your tip on removing "Anonymous Access" from ibi_cgi appears to have worked indeed! In comment on your response, I have been getting the popup prompting for credentials when first entering. What would happen though is that identity would be lost (no repeat popup either).
Thanks again...another hurdle passed Thanks To You!! Have a great day.
Bill