Great Write up. You should probably clarify something, though. When you say "When you load a page with two dynamic actions, the page will make three requests.", I believe that this is only true if the DA in question performs some type of server-side action or call-back. You absolutely need to be aware that any call-back to the server spawns a connection. So, pages which use heavy SQL or PL/SQL based DAs can mean heavy connection use. But fully client side DAs (to hide/show, etc) do not add to the connection requirements. Pedantic, I know, but worth talking about.

One thing to be wary of is that Chat-GPT MIGHT try to put comments in your JSON file. APEX will complain that the file is not compatible until you take those comments out. Other than that, it was smooth sailing - Thanks Matt! Great article.

Shyam, I don't have articles about Authorization and multi-tenant. However a simple google search on "Multi-tenant Authorization with Oracle APEX" turns up a few hits that might be of interest. Specifically there is a blog post by Jeff Kemp that might help. Good luck.

Hi Lionel, I fixed the broken password on the app. Should be working now. As for downloading the app, there is a link in the last paragraph that leads to a place on DropBox where you can download the app script. You don't need to have a DropBox account. If you still have problems downloading, let me know.

Ibrahim Wael Thanks for the comment and pointing out the error. Turns out that there was a typo in the function body. Where I referenced p_username it should have been p_user_name . I've fixed it in the main post, but changing that should make things compile for you.

Love this! Here is a set of links that I have used when I'm looking for the right type of chart to tell my data's story: Visual Vocabulary InfoGram.com visme.com BTW - I'm not affiliated with any of these. Just sites I've found interesting in the past.

Remember how above I stated that you really shouldn't be using the Authentication Scheme "as is" because it really isn't that secure? I am admittedly not a security expert, so normally I would engage someone who is to make sure anything that was going into production was air tight. Back at Oracle there was a whole process we had to go through that reviewed all security aspects of our applications before they were put live. And there were accepted patterns for things like Authentication. The code in this blog post would not pass muster! And with the help of Christian Neumueller of the APEX Team, here's why. The HASH_PASSWORD function is vulnerable to a "rainbow table attack." We hear all the time in the news about stolen user/password tables. If somone were able to get ahold of your USERS table, an attacker can build a table that contains username/likely-password/pre-computed-hash and compare the computed values with the stolen hashes. Once they have a match, they know the actual password. The solution is to salt the hashes and repeatedly apply the hash, e.g. using the PBKDF2 algorithm. Agreed. although there are many things you should be doing to make sure no one is able to get ahold of the underlying USERS table, if they were to get the data, this is a very valid point. The AUTHENTICATE_USER function is susceptible to a "Timing attack". The HASH_PASSWORD function does not get called when the user does not exist. Therefore, the code path for an invalid username is faster than the one for a valid user. Attackers can use statistical methods to determine whether they guessed a correct username. Your HASH_PASSWORD is fast, because it is simplistic and therefore inadequate - this algorithm MUST be expensive to make it harder for password crackers. In the real world this is a problem. Again, agreed. The authentication function does the bare minimum in my example and that's on purpose. I wanted something simple that didn't get in the way of the real meat of this article, which was the Authorization Schemes. BUT what this does prove is what I stated above ... That the authentication scheme is very basic** and is really here for demo purposes only** . It's not really meant for use in a production system. You'd likely want something far more robust such as a Single Sign On, Social Sign on or SAML based Authentication scheme. Thank you Christian for your excellent explanations.