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:
Well, let’s see what could go wrong.
Let’s try to start ORDS.
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.
Maybe you’re having a bad feeling about this. Are we really going to put the password in plain text into the config file?
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.
OK, so ORDS is running. Let’s go back and take a look at our pool config XML file.
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.