[Solved]Firewall security rejection

[cognosfreelancer]

Hello

I am having trouble running some SDK code that performed well in the QA instance but not in the production instance.

I have the same ReportNet environment in both QA and Prod.

I log in as the same user on to the server.

However when I run the code in production I get the following error message
"DPR-ERR-2079 Firewall Security Rejection. Your request was rejected by the security firewall" 

BTW - CAF is enabled on all servers.

Thanks

[Darek]

did you make sure that domains are specified in CAF?

[cognosfreelancer]

Darek

I have discovered the cause of the problem (but not the solution to it yet).

You see I am using an Eclipse plug in called 'Fat Jar' to create an executable jar file.

Running the above jar file gives the error. But running the .java file itself does not produce any errors.

NKT

[Darek]

Interesting. And both executions are using the same parameters? Or more specifically the same gateway URI.

[cognosfreelancer]

To sum up this is my problem.

Executable jar file runs fine when run from the QA server.

The same jar file gives the firewall security error when run from a separate server that hosts all scheduled jobs.

Both servers are on the same subnet and have no firewall between them.

The firewall that I am getting is from the Cognos Application Firewall software.

The QA and the scheduler server has Cognos configuration but the scheduler does not have any ReportNet component installed.

My next step would be to install FM and see if that helps.
NKT

[Darek]

Care to post the source code?

[cognosfreelancer]

Ok problem solved. (patting self on back  ).

The problem was resolved after I installed the Framework Manager component of ReportNet on the scheduler server.

Since the original problem was caused by the Cognos Application Firewall I guess the FM component brought the server under the purview of the CAF.

Food for thought about CAF. Might have to drop it in future installations.

NKT

[MrChuck]

Re CAF: My colleagues and I have had a lot of trouble with CAF at many sites and finally concluded that it's more trouble than it's worth.

It's not that well documented, and the diagnostics it produces when it's not happy are undercooked, to put it charitably, which makes troubleshooting tricky. It seems to cause complex interactions with other products that can be extremely hard to isolate. In large enterprises, the cognos team often does not have access to these other products (e.g. firewalls, enterprise directories) to change or even inspect their configuration.

I would be interested to see what other people's experiences have been, in anything other than small environments. In this sort of situation we would generally disable CAF first. You should not have to deploy developer components on a server to secure it--kind of defeats the purpose...

MrChuck.

[Darek]

I keep the CAF, but point any 3rd party app at the dispatcher URI. Gateways are protected by CAF. Dispatchers are not.