3 Replies Latest reply on Apr 10, 2012 2:37 PM by 863020

    page authentication problem under 4.1.1

      We appear to have a problem with page authentication under 4.1.1

      Our applications use standard Database Accounts authentication (Get UserName Cookie, etc) with a post-authentication procedure that builds a url based on the user id that has logged into the application. The construct:-


      is used to open the application on the relevant page for the user; where page_number is a value derived in the post-authentication procedure. This has worked without change from the earliest version of 3 through to 4 - but does not work under 4.1.1.

      Under 4.1.1, on attempting to login with a valid database userid & password, the user will remain on the login page. However, if page authentication is turned off on the target page (ie the page is made public), then the login completes and the target page is rendered. It would appear that the athentication fails because the session id has changed post login. The session id that is authenticated on login is not the same session id that is used post the owa_util.redirect. This then causes the page authentication to fail.

      We have tried the construct below as a work around to no avail:-

      -- Undocumented functions gleaned from Scott Spadafore's post here...
      -- Application Link
      -- See also: http://docs.oracle.com/cd/E23903_01/doc/doc.41/e21674/concept_url.htm#HTMDB03017

      l_cookie_session_id := APEX_CUSTOM_AUTH.GET_SESSION_ID_FROM_COOKIE;
      if l_cookie_session_id != :SESSION then

      select COUNT(*) into l_cookie_session_check from APEX_WORKSPACE_SESSIONS
      where apex_session_id = l_cookie_session_id;

      if l_cookie_session_check > 0 then
      -- The session in the cookie is a valid session now need to inject it into the query string

      -- Undocumented functions that apparently break apart the query string...
      end if;
      end if;

      apex_application.g_unrecoverable_error := true;

      This works in so far as that it keeps the original session id post login, but page authentication still fails – so the problem is more complex than just the session id?

      A simple app has been created that reliably reproduces the problem under 4.1.1 (on our development systems) but works OK on earlier version of Apex. This has been uploaded to apex.oracle.com in workspace authentication_error, application 26829, user test/test. However, to reproduce the error it is necessary to authenticate and login to the application as a database user. The schema id is "osl" but naturally there are restricted privileges around password changes for the schema & I am unaware of a "public" oracle user account that is accessible (what happened to scott/tiger).

      Is any of the Apex development team able to have a look, or anybody with similiar 4.1.1 experience able to comment on the cause and a workaround? You will need to be able to login as a database user (can you set a password for the schema owner and use this as the database account?) and then toggle page 1 between authentication and public.



      Edited by: 860017 on 06-Apr-2012 06:40
        • 1. Re: page authentication problem under 4.1.1
          Christian Neumueller-Oracle
          Hi Paul,

          the Apex engine tries to write a new value for the session cookie at the end of authentication. This was a security extension in 4.1.1. It fails, because your post-authentication code calls owa_util.redirect_url and already close the http header. On the next request ('f?p=26829:1:...session...'), Apex matches the session id with the cookie value and finds an old cookie, which causes it to reject the session.

          I changed the code to
              curl => 'f?p='||:APP_ID||':'||page_Number||':'||v('SESSION')||'::NO:::',
              bclose_header => false);
          and the app on apex.oracle.com lands on page 1 as expected.


          Edited by: Christian Neumueller on Apr 10, 2012 12:50 AM
          • 2. Re: page authentication problem under 4.1.1
            Christian Neumueller-Oracle
            Hi Paul!

            With bclose_header => false, the web servers get the following HTTP headers:
              Set-Cookie: LOGIN_USERNAME_COOKIE=... (set by the Set Username Cookie process on page 101)
              Location: f?p=.... (the redirect_url from your post-authentication process)
              Set-Cookie: PUBLIC-...=-1 (reset public cookie)
              Set-Cookie: WWV_CUSTOM-...=xxxx (set new value for session cookie)
              Location: f?p=... (the url Apex tries to redirect to)
            The problem is that web servers interpret the PL/SQL http headers differently. On apex.oracle.com the old OHS (mod_plsql) is used, it allows to set more than 1 "Location:" header for redirecting and just
            takes the 1st. The EPG and Apex Listener seem to get confused by the headers, they truncate everything below the 1st Location: header.

            We can use a different approach, since you will probably not want to change the HTTP server. Apex has this built-in item FSP_AFTER_LOGIN_URL, which is used to contain the deep link to the page that caused
            the login. After a successful login, the engine looks up the deep link value and redirects there. Your post-authentication process can simply set the deep link, to trick Apex to redirect there. So,
            instead of
                  curl          => 'f?p='||:APP_ID||':'||page_Number||':'||v('SESSION')||'::NO:::',
                  bclose_header => false);
            could you please try this?
              :FSP_AFTER_LOGIN_URL := 'f?p='||:APP_ID||':'||page_Number||':'||v('SESSION')||'::NO:::';
            • 3. Re: page authentication problem under 4.1.1
              Hi Christian

              Thanks for the input, we are using Apex Listener & Weblogic so your diagnosis has pinpointed the cause of the problem. The :FSP_AFTER_LOGIN_URL technique works as an alternative to using apex_util.redirect_url or owa_util.redirect_url.

              Many thanks.