Search for a command to run...
"Bumpy roads lead to beautiful places"
No comments yet. Be the first to comment.
This series will walk through the steps in order to install a local development environment that includes Oracle 23ai, ORDS & APEX.
You've Already Got Mail with OCI
I saw Dimitri's post on SQL Assertions today and it piqued my curiosity. Putting more business rules closer to data is almost always a great idea, as you can now call DML from any technology and rest
Almost 20 years ago to the date, I submitted my resignation to Oracle to go start my own company. It was a difficult decision to make, as APEX - or HTML DB as it was called then - was just starting to gain traction. However, I was presented with an o...
One of the more difficult parts of the software development lifecycle is deployment. While it seems simple on the surface - just write some scripts and run them - it gets pretty complicated pretty quickly as the level of sophistication of your system...
Another AI-centric tool that has raised a lot of interest is Claude Desktop. Like Cline, Claude Desktop uses the same reasoning engine at the core - Claude Code - to assist with development tasks. While they share the same engine, there are use cases...
When I first heard the term MCP used in the context of AI, I was immediately taken back to the 80s when the movie Tron was released. For those who have not seen it, Tron is a futuristic movie about a curious user who is literally sucked into a comput...
Something just doesn’t feel “right” about running a development environment on a non-standard port over just HTTP. Not only is it bothersome to see the “Not Secure” message, it’s not a best practice. Your development environment should be as close to your production environment as possible.
While the main difference is that HTTPS will encrypt data in transit and HTTP will not, there’s another subtle one that’s also important. HTTPS pages will not allow Javascript to be called from HTTP-only URLs. Thus, if you don’t use HTTPS, this issue would not rear its ugly head until you deployed to production.
It only takes a few minutes to get up and running with your own, trusted, self-signed certificate. The initial first few steps work for both Mac & Windows. Pay attention at the end, as adding the self-signed certificate as trusted varies across platforms. I’ve added a section for each OS.
Let’s start by creating our self-signed certificate.
Open a new terminal window
Navigate to the ords_config directory. This was set up as part of my previous post here.
Create a new directory called ssl.
Navigate to the ssl directory.
Run the following command:
openssl req -x509 -out cert.crt -keyout key.key -days 9999 \
-newkey rsa:2048 -nodes -sha256 \
-subj '/CN=localhost' -extensions EXT -config <( \
printf "[dn]\nCN=localhost\n[req]\ndistinguished_name = dn\n[EXT]\nsubjectAltName=DNS:localhost\nkeyUsage=digitalSignature\nextendedKeyUsage=serverAuth")
Some notes about this command:
The bulk of this command was taken from this page: https://letsencrypt.org/docs/certificates-for-localhost/
I set days = 9999 because I don’t want to be bothered to re-create this certificate. Ever.
The name of the certificate pair - cert.crt & key.key - are what the ORDS container will look for, so don’t change them.
Upon running this command, you should have two files in the ssl directory:
A simple restart of the ORDS container is all we need to switch over from HTTP to HTTPS.
Remember what I said about that non-standard port? Let’s change that to 443, so that we don’t need to put a port number in the URL at all.
Terminate your existing ORDS container.
Using this new command, restart the ORDS container:
podman run --rm --name ords -v `pwd`/ords_secrets/:/opt/oracle/variables -v `pwd`/ords_config/:/etc/ords/config/ -v `pwd`/images/:/opt/oracle/apex/24.1.0/images -p 443:8181 container-registry.oracle.com/database/ords-developer:latest &
This command has one additional argument in it: -p 443:8181 That additional attribute will redirect port 8181 from the container to your local port 443.
As keen readers may have noticed, I’ve saved this command to a local file called start_ords. This way, I can just run that file to restart my container vs. sorting through my blog to find the command syntax.
Let’s see what happens now what we try to access our ORDS container.
https://localhostAs expected, you should see the “Your connection is not private” error. This is because the certificate is self-signed, and the browser cannot associate it with one of it’s CAs.
You can click “Advanced” and then Proceed to localhost (unsafe), but that gets annoying pretty quickly.
While theres a number of ways to fix this issue, the quickest one that I have come by is to tell your local machine to simply “trust” this self-signed certificate as if it were signed by a legitimate CA. This takes just seconds, and agains, since this is a local development environment, is a perfectly secure approach to take.
Trusting the certificate will vary, depending on your local OS.
To trust a self-signed certificate on Mac OS, we simply need to add the certificate to the MacOS Keychain.
Launch the application called Keychain Access.
Enter your credentials.
You should now see a window similar to this:
Using the Finder, navigate to the folder where you placed the certificates that you created earlier. It should be in /ords_config/ssl.
Drag the file cert.crt to the “striped” part of the Keychain Access window (under the column headings). You should see the following popup window:
Select Add.
On the main Keychain Access window, search for localhost. You should see a single entry:
Double-click the localhost entry.
Expand the Trust region.
Set When using this certificate to Always Trust. All other options should automatically change to Always Trust as well.
Close the localhost window. You will need to re-enter your credentials for the changes to take effect.
At this point, your local OS will trust our self-signed localhost certificate as if it were valid. You will no longer see the “Not Secure” message, either. Again, fine for development, not really a great idea for production systems.
We can prove this by reloading our browser that was pointed to https://localhost.
The results should look like this:
On Windows, you need to take similar steps to allow the OS to trust the self-signed certificate.
I did some searching, and this post seems to have a decent set of steps to do this. I did not have the chance to try this out, so please leave a comment if it doesn’t work or you have a better set of steps to use on Windows.
Even though it’s a local development environment, it’s important to try to mirror what’s on production as much as possible - including the protocol used to access APEX. It doesn’t take much work to create and install your own certificates into the ORDS container, ensuring that all web applications are accessed via HTTPS.
Title Photo by Fer Troulik on Unsplash