ORDS_PUBLIC_USER is the database user that’s used to create your ORDS connection pool(s). Each database configured with ORDS gets one.

When you publish a RESTful Service under HR on database X, ORDS resolves the call to the proper jdbc connection pool, then proxy connects from ORDS_PUBLIC_USER to user HR, and runs the SQL or PL/SQL.

So, now imagine what happens when you let the ORDS_PUBLIC_USER password expire? Or even worse, someone does this:

What could go wrong?

Well, let’s see what could go wrong.

Let’s try to start ORDS.

Ruh-roh…

In case you can’t read that text, ORDS is having an issue with one of our connection pools.

SEVERE: The username or password for the connection pool named apex_pu, are invalid, expired, or the account is locked

So, you could unlock the account, or simply change the password BACK to what it was when ORDS was configured for the database.

But, what if you need to tell ORDS what the new password is instead?

Update the connection pool properties file.

Go into your ORDS config directory.

There will be an XML file in there for each connection pool.

Edit it with VI or notepad, and update the password field.

This seems bad to me?

Maybe you’re having a bad feeling about this. Are we really going to put the password in plain text into the config file?

Kinda.

Note the ‘!’ in front of the password string. This tells ORDS to re-write the password back out hashed when it starts up. So let’s do that, and see what happens.

Start ORDS back up.

This looks MUCH better.

OK, so ORDS is running. Let’s go back and take a look at our pool config XML file.

That’s NOT what we put in there.

So the ORDS process has written the file back out.

!string = ORDS, please take this new password for the pool, then write it back such that no one else can read it, please.
@string = ORDS is using this password, but you can’t see it.
string = ORDS, this is the actual password, don’t touch it.

Remember, you need to restart ORDS for it to pick up any changes in its config files.

thatjeffsmith
Author

I'm a Master Product Manager at Oracle for Oracle SQL Developer. My mission is to help you and your company be more efficient with our database tools.

19 Comments

  1. My question is related to generate Authorization token.

    What is ORDS_PUBLIC_USER role for authorization token generation?

  2. Hi Jeff,
    I know this is an old thread, but I have a related question. Can the pool config file be changed and ORDS pick it up with a restart? We’re running 18.4.

    Thanks.

  3. If ords_public_user does what you say then what is the point of apex_public_user?

  4. This post helped me solve my issue with ords3 and now ords18

    We are using passwords beginning with an ! (exclamation mark).
    With ords2 this seems to work fine.
    With ords3 and later: On first deployment of ords in tomcat the listener works fine. After restarting tomcat I get a 404 and ‘The pool named: |apex|| is invalid and will be ignored: The username or password for the connection pool named apex, are invalid, expired, or the account is locked’ in the logfile.

    I have changed the passwords for APEX_PUBLIC_USER , APEX_REST_PUBLIC_USER , APEX_LISTENER and ORDS_PUBLIC_USER to passwords not beginning with an ! and now it works fine.

  5. Can you tell me what method is used to encrypt the file? I work for the DoD and they require a FIPS compliant encryption method.

  6. It used to work for me just fine, but with latest ords.18.1.1.95.1251 prefixing password with ! results in error:

    apex.xml:

    Generated by Ansible
    !apex_public_user
    APEX_PUBLIC_USER

    Result is failure:
    The pool named: |apex|| is invalid and will be ignored: The username or password for the connection pool named apex, are invalid, expired, or the account is locked

    But with apex.xml:

    Generated by Ansible
    apex_public_user
    APEX_PUBLIC_USER

    Result is good:
    02-May-2018 14:12:02.211 INFO [localhost-startStop-1] . Creating Pool:|apex||
    02-May-2018 14:12:02.226 INFO [localhost-startStop-1] . Configuration properties for: |apex||

    File is readable/writable by tomcat, SELinux disabled 🙂

  7. It helps me to avoid a full reinstallation of ORDS env. It was APEX_REST_PUBLIC_USER that was blocked but solution was the same.

    Thanks a lot….

    • Gauss Reza

      Hi Jeff,

      What about Passwordless schemas/accounts.
      Why not integrate it with these ORDS config so that this issue does not happen ever, because there is effectively NO password!
      Something to think about, eh?

      Regards,
      Gauss

    • thatjeffsmith

      Except…ORDS_PUBLIC_USER is an account that actually logs into the database.

      Passwordless accounts are for application schemas that don’t actually have USERs that do things like login. But we most definitely DO login.

Write A Comment