Skip to main content

Kotlin Notebook when you're blocked from Maven Central

 TLDR;

If you are blocked getting to maven central when first using Kotlin Notebooks because of company firewalls, you can use a tool like Fiddler Tool to redirect to a different network location.

Kotlin Notebooks

Kotlin Notebooks are a JDK based environment that brings the Python based Jupyter Notebooks expressiveness to IntelliJ.

From the blog post announcing the plugin, it looks like this:


At home, the installation of jar files looked like this:



I played around with it at home, but I couldn't use it at work.  Many companies, mine included, do not allow software components to be used when downloaded directly from the internet.


In my companies case, we use a product called Artifactory, which allows you to mirror the content from Maven Central while still applying policies like CVE scanning, tracking, etc.

The way it should work

IntelliJ, as one of the leading IDE's, generally supports this quite well.  In fact, there is a whole setting page dedicated to dealing with just this situation:


If I were at work, this settings page would have configuration that pointed to where I'm allowed to get Maven Central jar files.

Unfortunately, the client/server configuration of the Kotlin Notebook plugin doesn't seem to honor this page and tries to directly access Maven Central.

The workaround

Because I have to inject my personal credentials into the request for jar files, a simple redirect generated by the TLS connection would not work.  I actually have to be able to read and adjust the layer 7 HTTPS traffic.  One of my favorite tools to do that is called Fiddler . Not only is it able to act as a proxy on my PC, it's has a redirect option that is easy to use.


Set your proxy to http://127.0.0.1:8888 (unless you needed to change Fiddler's defaults):

And the necessary jar files will be downloaded.

Cleanup required

Fiddler has to have the option to decrypt TLS/SSL turned on in order to view the layer 7 HTTP request.  This means that you will receive multiple "Do you trust this certificate?" questions from IntelliJ.

You will now have TLS certificates trusted in IntelliJ's cacerts file (usually found at C:\Users\<username>\AppData\Roaming\JetBrains\IntelliJIdea2023.3\ssl\cacerts) that you DO NOT WANT to keep trusting.  Delete the entries with Fiddler in the name using keytool, reset your proxy back to not use 127.0.0.1:8888 and you should be on your way.

Comments

Popular posts from this blog

Spring Boot native builds when internet downloads are blocked made simple

 No direct access to the internet If you work at a company that controls their software bill of materials, it's quite common to be blocked from directly downloading from: Maven Central Docker hub GitHub (the public parts) Getting the bits Maven Maven is first, because without it, you won't be able to compile your Spring Boot application, let alone move on to turning it into a native docker image. I will be showing changes need to work with artifactory, but you should be able to adapt it to other mirror solutions.  repositories {   maven {     name = "central"     url = "https://artifactory.example.com/central"     credentials {       username = "${project.ext.properties.artifactory_username}"       password = "${project.ext.properties.artifactory_apikey}"     }   } } With this configuration change, you should be able to download your plugins and dependencies, allowing you to compile and ...

Active vs. Passive Log4jShell remediation

 Log4jShell  All computer professionals should be aware of the Log4jShell ( CVE-2021-44228 ) and it follow on defects.  There is no shortage of opinions and lessons to be be learned: The difficulty of performing safe interpretation The problems when assumptions are not clearly documented.  I, for one, was completely shocked to find out that a logging system would actually attempt to do variable substitution in an actual message. The difficulty of finding and resolving issues with such a common library that is not provided by an OS package manager. IT'S A LOG4J CHRISTMAS One of my favorite podcasts, Security Now - episode 850 , discussed an analysis by Google regarding the depth of log4j dependencies.  From the show notes : One contributing reason is because Log4j is, more often than not, an indirect dependency. Java libraries are built by writing some code which uses functions from other Java libraries, which are built by writing some code which uses functions f...