can you reproduce that error? Does it always happen at the same page? Is that user somehow different to others (special characters in name)?
Did you take a look into the APEX Debug Log? Or under Administration -> Monitor Activities -> Application Errors?
To get more Debug-Output of your APEX Session you can set the Debug-Parameter in the URL to LEVEL9 instead of YES.
Thanks Peter for your reply,
We are unable to reproduce this. It just happens :-)
It's not page, workspace, application or user related, that's why it doesn't show up in any error log.
Most of the times, it occurs in the application builder when submitting a page. Can I enable logging here too?
I'll give the LEVEL9 suggestion a try but it won't help me in the application builder I'm afraid.
what you are describing could be that WebGate runs into some limit (e.g. OAM session idle timeout). In those cases it intercepts the incoming request and redirects to Access Manager, for some verification. If that succeeds, the control goes back to WebGate with a redirect and it continues with the original request. However, if that original request was a POST (e.g. wwv_flow.accept for a page submit), it performs the request without the POST parameters. The "No Data Found" you see could be that APEX does not even get an application id for the request and gets 1403 when trying to look up application metadata. There are some Access Manager configuration options to prevent these problems. It also significantly helps if OAM is configured such that WebGate only ever protects apex_authentication.callback for APEX requests, no /i/ or other /apex/ requests.
Your best option is to get in contact with Oracle Support. This issue probably depends on how OAM and WebGate is set up at your site. I found bug 16212631 (it was filed as an APEX bug, but actually was a configuration issue) where I worked with them on improving the OAM integration for a customer. It might help to mention this bug in the SR. Here is an excerpt from my explanation in the bug:
We define 4 resources:
1. /apex/apex_authentication.callback: Authn=Protected, Authz=Protected
2. /.../*: Authn=Public, Authz=Public
3. /apex/apex_authentication.callback/.../*: Authn=Protected, Authz=Protected
4. /apex/.../*: Authn=Public, Authz=Protected
(Authn = Authentication, Authz = Authorization)
Both under the Authn and Authz Protected Resource Policy, we define 3
1. HTTP_OAM_REMOTE_USER_GROUPS: $user.groups
2. HTTP_OAM_REMOTE_USER_EMAIL: $user.attr.mail
3. HTTP_OAM_REMOTE_USER: $user.userid
The Protected Authz Policy has Use Implied Constraints checked.
Thanks for your reply.
I talked things over with our DBA team and your explanation got them thinking.
The resources and headers you talk about are set-up correct so this could not be the issue but the symptoms are as you state (POST request without parameters).
We've gathered some more stats and have prepared a SR.
Before we log this, we'll perform the same tests on our acceptance environment which is running on a higher version of OAM.
Our development environment is running on release 184.108.40.206 of OAM whereas our acceptance environment is running on 220.127.116.11. Release numbers got mixed up in my initial post.
If the problem persists on 18.104.22.168, we'll log a SR. If it doesn't we'll upgrade our development environment to a higher version.
Thanks a lot for your help!