This content has been marked as final. Show 22 replies
sorry, it seems like I introduced a bug with the 4.2 optimizations to session handling. It can cause this problem with certain custom sentry functions. I filed #14784118 for this issue and we'll get a PSE out.
The root cause for this problem is that a function which returns session data now caches the information, to avoid querying for each access. However, it does not create a new session for the ID your code created with wwv_flow_custom_auth.get_next_session_id, if it already has the builder session in it's cache. When your sentry tries to save the deep link in session state, this fails because the session record itself does not yet exist.
I'll update the thread when the PSE is ready.
Thanks. A few thoughts come to mind
1. I participated in the early adopter/beta program and didn't encounter this bug. It must have been introduced just before release.
2. It is a little troubling to see similar bugs in the same area for the third time in as many releases. You may recall our Apex 4.1 - Websheets with custom authentication scheme Re: 4.1 POST_LOGIN question on this topic. How do these bugs slip past a public beta and Oracle's own internal QA process?
3. If I understand you correctly, this bug only shows up when running the app when logged into the App Builder. So it is safe to deploy 4.2 in a Production environment without running into this bug?
4. As I described earlier, even in a Builder session, when I initially login and run my app I get the error. Now when I logout from Builder and log back in and run the app, I DO NOT get the error. Why is this?
(1) The bug was introduced on 2012-05-10.
(2) Sorry again. I can not describe our internal processes, but we (the development team) are actively working on additional test automation that should catch these kinds of issues in the future.
(3) The bug only shows up if Apex can find a builder session for the same workspace. On a runtime (i.e. production) env, there can never be a builder session.
(4) I can not reproduce that. If I'm logged into the builder for the same workspace, the app sentry throws this error. It does not matter if I logout and login again.
Regarding (4), here is what I observed.
0. Firefox - Use Tools/Options/Privacy/Cookies to clear all apex.oracle.com cookies
1. Tab 1 - Login to apex.oracle.com. Run app 24317 via the Builder. Get the error.
2. Tab 1- Logout of the builder.
3. Tab 2 - In a new tab, run the app directly by typing in http://apex.oracle.com/pls/apex/f?p=24317 , no error
4. Tab 1 - Repeat step 1. This time there is no error!
Note that the session id in the browser location bar in step 3 (no dev toolbar at the bottom of the page since no builder session was active at that point in time) and step 4 is different. But clicking around the app in the tab in step 3 now does show the dev toolbar at the bottom indicating that it has "joined" the now active builder session.
Does that help? Are they all symptoms of the same underlying issue?
I know that the question is marked as answered but I wanted to let you know that we have similar problem and in my opinion the problem does not correspond to the builder session and my happen on production env.
Recently we have upgraded to 4.2. Our sentry function looks very similar to this one from Joel R. Kallman blog: [http://joelkallman.blogspot.fr/2010/10/custom-authentication-scheme-for-oracle.html]
It is a http header variable authentication. Unfortunately because of user requirements we could not use the one which is coming with APEX. Our URL which is used to access APEX application is protected and can be only accessed by the users which have authenticated in our SSO. In this case http header variable will be injected to the HTTP request.
Get to the point. When user first access application and authenticate problem will appear - ORA-02291: integrity constraint (APEX_040200.WWV_FLOW_DATA_SESSION_FK) violated - parent key not found. If you delete session id from the URL it will start to work.
Could you please help us? Thank you in advance.
I tested Joel's sentry function and it showed the same behaviour as Vikas' function. However, you are correct that the error can also occur when the URL contains a session id that already exists, thanks for pointing that out. It turns out that the session gets loaded into the cache, but it can not be used by the request, since the session cookie is null after a browser restart. My initial assumption that this can only occur when a builder session exists was wrong, but the underlying issue with the caching mechanism is the same. The fix I implemented solves both problems. It's currently under review but we'll have a patch available soon.
Christian - Did you review my last post to the thread? I am not sure I understand if this is a 3rd symptom of the same bug or not. The 2 symptoms you have identified so far are 1) app session run via Builder and 2) URL has session id but no session cookie. The step-by-step I provided shows how logging out and running the app without session id in another tab and then logging in to the Builder results in no error. What explains this?
Also, users frequently email links containing session ids around. For example, user A copies the link he sees in the browser f?p=123:45:12345 and sends it to user B. User B clicks on the link and the since User B's browser doesn't have a session cookie for Session 12345, the page sentry transparently creates a new session, sets the cookie for it, and redirects to it. But because of this bug (Maciej's symptom), User B would get the error, right?
So, are you still confident about your earlier recommendation that we will not encounter this bug in a Production environment in the absence of a builder session? Or should we wait for the patch you are working on before upgrading Production to 4.2? Please advise.
I did and I can explain this behaviour. The difference is that in your step 4, a valid cookie for your app session exists. Before Apex executes the application's sentry, it already tries to set up the session, based on the session id in the URL. Now that is the builder session if you run from the builder, but there is a special optimization in that setup code that switches g_instance (i.e. the session id during the request) to the application session. That code requires that the URL's session id is for the builder, a valid builder cookie exists and the app session cookie references a valid application session. If these conditions are met, Apex treats the request as if it was executed with the application session id which matches the app session cookie. If we didn't have this code, each switch between builder and runtime would invalidate the application session and you would have to login again to the app.
Maciej's finding shows that the error can also occur in a production environment, in the absence of a builder session. My fix should be downloadable from Oracle Support soon, I guess some time this week, but that's outside of my control. Based on the scenario you described, with users sending links around, it might make sense to wait. For others it might be ok to upgrade right now.
Edited by: Christian Neumueller on Oct 23, 2012 7:12 AM
I just applied your patch, but it is still not working. This time the URL gets refreshed with new sessionIDs and I can see the numbers changing in the URL(and it tries to reload the page like several times in a minute) and it does not render the page. We are not getting the FK violation error though.
Thanks Christian for helping me out. This is when I run on IE
as a workaround you might want to have a look at our "HTTP Header Variable" authentication scheme which we introduced in APEX 4.1. I think there is no need anymore to use a custom authentication to authenticate against Siteminder.
Here is what you have to do:
1) Create a new authentication scheme using the type "HTTP Header Variable"
2) Set "HTTP Header Variable Name" to SM_USER
3) Set "Action if Username is Empty" to Redirect to built-in URL (see online help for other options if you want to use your own URL)
4) Configure Siteminder to protect the URL */apex/apex_authentication.callback* to enforce an authentication of your application with Siteminder.
5) Check if Siteminder always sets the SM_USER environment variable for following requests, if not set "Verify Username" to "After Login".
Hope that gets you going.
My Blog: http://www.inside-oracle-apex.com
APEX Plug-Ins: http://apex.oracle.com/plugins
Thanks Patrick, that is what I am doing in development environment now. But the problem is, we have lots of application using this custom SSO, and when I upgrade the apex instance in production all the applications will stop working, and it is very difficult to coordinate all the stake holders to roll out their app as soon as the upgrade is done.