I've been searching the docs and forums for awhile and can't come up with anything.

How can I can get rid of the prompt for reporting server credentials for a specific self service page? I don't want to make all self-service pages public, just this one and maybe others. I don't want to hard code a valid user/password in the code so any web user looking at the source code could see this.


Any suggestions?

Thanks,
Nate

Hi Nate
I have public web site using WF server, the techniques I have had to use for secure access are a little complex, and not what I would want to share on a public forum.
Send me a private message if you would like further details on ONE way this can be managed.

As Alan mentioned, there are a number of different ways to solve this. One that we used for quite a while was to create another instance of the WF server (this doesn't require another license as long as it's on the same platform/OS image). This server can have security off (which isn't very safe) or turned on with valid credentials set in the site.wfs or cgivars.wfs so that there is a valid/authenticated default user that requests the connections. This server can then be set up to serve all of your self-service applications with access only to those resources required for that application.

Another way to do this is to set up a simple public dashboard that has your application served on one of the pages/tabs. In the setup of the dashboard you can specify a valid userid/password combination that the public user will use. This locks it down a little more because you can control what the user sees and does within the dashboard, but requires the use of the dashboard component.

If you are wanting to secure a focexec then you could check to see if the value of IBIF_ex is ok and if so then set the userid and password for the reporting server.

NOTE: When it comes to licensing I would be sure to check with your Account Rep. and not just trust anything anyone says here on the forum as anyone can post virtually anything they want.

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

All fexs are secure...I want to unsecure ONE of them. (by getting rid of the prompt for credentials)

I don't want to make everything unsecure by having values on the Webconsole for default credentials.

Thanks,
Nate

I would go with setting it up in a public dashboard. I don't think there is really a way to have the same server treat one procedure different than another as far as authentication goes, except to run it through a different "environment" like dashboard or a separate server that is set up for self-service apps. If you're going to be doing more in the future, I would consider this as well.

One other thought I had that I've seen used is using a JSP to hide all the credential info. It's in a class that gets called at the time the report is submitted and adds the info to the submit string, but the user can never see that. You can then just call the JSP from a URL in whatever application or HTML page calls you self-service report. I can probably get more info on that if you're interested.

NOTE: I agree with Texas that you should check with you Acct rep when it comes to licensing. I just happened to know the answer to that one because I was an IBI SE for 8 years. Thanks for the word of caution.

Nate,
How about a self-service app where the app would manage the users in a way where if a user would "log-on" with a preset userid and pwd the subset of fexes would be accessible, but if a personal userid's was entered then another subset or a superset would be active?

In order to do that you would need to define who is authorized to do what in a table or tables. Once you've built the requisite authorization model you could run a fex at sign on that brings back authorizations for that specific user from the authorization tables. The authorizations can be built to bring back a custom menu of reports for the user, customizaed WHERE clauses, or perform other user specific tests. Alternatively, the Managed Reporting Environment provides that for you out of the box.

Darin mentioned the use of JSP which may be a nice approach in having public access to a basically secure server. I mix WebFocus with ASP, which is like mixing oil and water, but is exactly what I want to achieve as each of them cannot understand the other, a sort of non-relationship which I take advantage of. My saviour has been the use of AJAX.

Never underestimate the side effects of opening up a site, with any form of company data, to the public. It is not just a WebFocus issue. The HTML, javascript and cookies are an open book out there, and remember a focexec or program can be just a URL away.

Essential reading is the WebFocus Security and Administration manual that covers the many ways of using security and includes many different ways that can be utilised to help control the environment. I have spent many happy hours reading it .

In WebFocus it is not the case that you can un-secure a focexec to stop someone using it, it becomes a case of how to secure access to a focexec effectively. (If I remember correctly from a previous topic, FrankDutch was working on something like this.) For me, as I am writing a replacement system, the security of the system was built in from the start, with the lessons of 7 years behind me, so it becomes 2nd nature though I am still learning. And just one approach never seems to cover ALL the bases, I have used 3 seperate methods depending on circumstances, basically split into reporting, maintain and Update Assist, what works for one may not/does not work for another.

How bad can it be? There was one customer that very nearly managed to run our reports from within their own web site, unknown to us, and uncontrolled by us. Another customer needed to, was actually encouraged by the sales staff, to do just that.

Open and secure do not sit comfortably together.

Mr Bell,

quote:

I have spent many happy hours reading it

and I thought I was an adict
T