4 Replies Latest reply on Jan 23, 2019 11:10 PM by 2949086



      Hi all,


      I am one of the many people I've seen on the forums attempting to migrate an old mod_plsql application over to ORDS. The additions of jdbc.auth.enabled and security.requestValidationFunction in recent versions have been huge, as I've managed to get the old application working almost 100% using either standard HTTP Basic authentication or OWA custom authentication (using owa_sec routines for username/password prompting).


      However, the one issue I'm running into is being able to logout of the application. With mod_plsql, you would set the WDB_GATEWAY_LOGOUT cookie to "YES", and then when mod_plsql saw that, it would unset the cookie and append the timestamp to the realm (DAD) name, effectively requiring you to login again.


      I can't get this to work with ORDS - it seems to ignore the cookie altogether.


      a) When using ORDS HTTP Basic by setting jdbc.auth.enabled to true, the cookie gets set, but ORDS doesn't care - the next time I try to login, it uses the same realm name and the same cached login credentials, so it lets me back in as the user I logged out as.


      b) When using ORDS Custom authentication by setting security.requestValidationFunction to my OWA_CUSTOM.authorize function, I have similar issues. With mod_plsql, my authorize function would check for that WDB_GATEWAY_LOGOUT cookie, clear the username/password using OWA functions if it was set, and then call owa_sec.set_protection_realm to prompt for username and password again. mod_plsql would take care of unsetting the cookie and appending the timestamp to the realm, so it would work just like HTTP basic authentication. But since ORDS ignores the cookie and doesn't unset it, I just keep getting prompted for username/password (since my authorize function keeps unsetting them due to the presence of the cookie) until eventually I hit a 401.


      I'm currently using a javascript hack where I submit an ajax request in the background with purposely bad login credentials to effectively force me to get prompted again upon login, but it's not very clean. There's a delay while the authorization failures are happening, and users will definitely notice.


      Are there any plans to add support for the WDB_GATEWAY_LOGOUT cookie to future versions of ORDS? Or does anyone have an idea of how I can hack it together myself? Eventually we're going to completely re-design the authentication mechanism for this application, but since Oracle has already done so much to help us mod_plsql migrators, I'm hoping maybe they can do one more little thing and add this in. :-)


      Thanks to anyone who has any ideas!


        • 1. Re: WDB_GATEWAY_LOGOUT support in ORDS?

          The problem boils down to this, from the Docs


          • Basic dynamic authentication: The users provide credentials in a browser HTTP basic authentication dialog box. The only way to log out is to close all the instances of the browser.


          We tried many different ways to simulate or force a 'log out' using Basic Auth, and it's just not possible.

          • 2. Re: WDB_GATEWAY_LOGOUT support in ORDS?

            Thanks for the response Jeff.


            But from administering this mod_plsql application for the last few years, I can tell you that mod_plsql handles the logout with HTTP Basic Authentication just fine.


            Check out this documentation - it's from OHS 10.1 but it still holds true with Web Tier




            Specifically, section 3.2 on deauthenticating users. We don't use the "logmeoff" URL, but we implement a custom logoff routine that sets the WDB_GATEWAY_LOGOUT cookie to YES and returns to the main page. When we try to login again, we're prompted for username and password, all without closing the browser.


            I thought I read somewhere the details of exactly how mod_plsql accomplishes this, but I can't seem to find it. But here's what I recall...


            If you access a DAD using dynamic authentication, and mod_plsql sees the WDB_GATEWAY_LOGOUT cookie set, it does two things:


            1) It changes the Basic HTTP authentication "realm". The realm is normally just the name of the DAD (i.e. "mydad"), but mod_plsql modifies it by appending the current timestamp (i.e. "mydad [@Wed, 23 Jan 2019 15:49:59]"). This tricks the browser into thinking it's logging into something different than "mydad", even though it's the same application, so the username/password prompt comes up again. Somehow, an additional cookie WDB_TIMESTAMP (which includes the timestamp appended to the realm) gets set and sent from the browser to mod_plsql during this request. I'm not exactly sure where this is coming from, but I assume it's something mod_plsql is doing behind the scenes.


            2) In the response headers after the request has been authenticated, mod_plsql "unsets" both WDB_GATEWAY_LOGOUT and WDB_TIMESTAMP cookies, setting the former to "NO" and expiring it 01/01/90 and setting the latter to "" and expiring it 01/01/90. That prevents mod_plsql from changing the realm again until our code resets the WDB_GATEWAY_LOGOUT cookie the next time they logout.


            This is the functionality I'm hoping makes its way into ORDS to round out its "legacy mod_plsql support" feature set and help tide us over until we can move to a more robust authentication mechanism. Is there a place where I could submit a formal feature request?




            • 3. Re: WDB_GATEWAY_LOGOUT support in ORDS?

              My Oracle Support for enhancement requests


              but as I understand it, our position is that you should look at changing your authentication scheme to something like OAUTH2

              • 4. Re: WDB_GATEWAY_LOGOUT support in ORDS?

                Understood, and changing the authentication scheme is the ultimate and eventual goal. But since the ORDS team had already made so many other accommodations re: HTTP Basic Auth support for those of us trying to migrate legacy apps from mod_plsql, I was hoping the logout cookie part of it would be included. I guess it wouldn't hurt to submit the enhancement request and see what happens. Thanks for your help.