DEV Community: Ope Adeyomoye

filterd: AI-based Image Moderation for Everyday Websites

Ope Adeyomoye — Fri, 14 Jan 2022 07:50:47 +0000

Overview of My Submission

filterd is a concept of a company that offers an API to help detect and tag potentially offensive content in images, using AI.

A sample use case would be to automate content moderation on blogs / forums / others websites where end-users are allowed to put up images.

The submission includes customer sign-up, authentication, API key issuance, and an API endpoint for annotating customers' images.

On annotating an image with the API, the customer gets a "suggestion" to express accept or decline posting the image on their website. If the analysis is inconclusive, they're nudged to manually review the image.

All data is stored in MongoDB Atlas.

Submission Category:

Choose Your Own Adventure

Link to Code

opeadeyomoye / filterd

filterd

AI-based content moderation.

See https://filterd.cloud

View on GitHub

Additional Resources / Info

The project uses Cloud Vision, MongoDB Atlas and a PHP backend.

Screenshots

Volafile

Ope Adeyomoye — Mon, 11 Jan 2021 06:42:36 +0000

What I built

A simple, ephemeral file-sharing service.

Category Submission:

Built for Business

App Link

https://volafile-76j4i.ondigitalocean.app

Screenshots

Description

Volafile helps you share files privately. You can upload a file and get a unique download link that's known only to you and other people you might share it with.

You can optionally add another layer of secrecy with a password. That way, if you accidentally share your download link in the wrong places, your private files don't suddenly become publicly available. Any one with the link will need that password before they can access your file(s).

At the moment, each upload automatically expires after 24 hours, so any attempts to download your file(s) after that time will fail and your files are permanently deleted.

Link to Source Code

https://github.com/opeadeyomoye/volafile

Permissive License

MIT

Background

Firefox Send was a lovely service before it was taken down. It was great to have a way to securely make anonymous, short-lived file shares. Volafile is inspired by the late Firefox Send.

How I built it

Volafile currently runs as a traditional web app in 1+ Docker containers on DigitalOcean's App Platform. It also uses a MySQL database based on DigitalOcean's managed database service and stores uploaded files with Spaces.

Securing your Azure Web App with Let's Encrypt.

Ope Adeyomoye — Mon, 20 Apr 2020 03:12:27 +0000

This post assumes that you have deployed your web app in a Docker container on Microsoft Azure's fully-managed App Service platform. It also assumes that, for some reason, you want to manually obtain an SSL certificate for your app, and manually renew it before it expires.

Before we get to certificates...

When you deploy your app on Azure's App Service platform, you automatically get a URL that can be used to view your app. It'll usually be in the form: https://your-app-name.azurewebsites.net. If you like the free domain and don't exactly see a need to use a custom domain, then you probably don't need most of the rest of this post. I'd suggest you turn on "HTTPS only" tho.

Chances are, however, you do want to serve your app using a custom domain. If you've not added a custom domain to your App Service app, please see Azure's docs on this and follow the steps there.

It could be much easier

Azure lets you create a free certificate and add it your App Service app at the click of a couple buttons. It's issued by DigiCert, managed by App Service, and renewed automatically.

If you'd like to use this instead of rolling your own, see Azure's docs on it and don't forget to turn on HTTPS Only.

Getting a certificate

Let's Encrypt recommends using the Certbot ACME client for certificate issuance. Certbot can automate certificate issuance and installation, but this post demonstrates using Certbot in manual mode.

First, let's install Certbot. On Debian 10+ systems:

$ sudo apt-get update
$ sudo apt-get install certbot

For other Debian versions, linux distros or different operating systems, please see Certbot's installation docs.

Issuing a certificate

Now, let's get an SSL certificate issued for yourdomain.com. On the command line:

$ sudo certbot certonly -d yourdomain.com --manual --preferred-challenges dns

That command:

via the certonly sub-command, tells Certbot to simply obtain a new certificate, and not install it on your local machine;
tells Certbot to use a DNS challenge. As opposed to an HTTPS challenge where you'd have to upload a certain file to a specific directory on your server, a DNS challenge requires you to add a DNS TXT record on your domain.

After a few simple questions, Certbot will ask you to create a DNS TXT record, usually under the name _acme-challenge.yourdomain.com, with a value it provides. Usually, you'll do this via your DNS provider. Please see your DNS provider's docs on how to create DNS records for your domain.

If it all went well, you should see a message like this:

IMPORTANT NOTES:
 - Congratulations! Your certificate and chain have been saved at:
   /etc/letsencrypt/live/yourdomain.com/fullchain.pem
   Your key file has been saved at:
   /etc/letsencrypt/live/yourdomain.com/privkey.pem
   Your cert will expire on <some-date>. To obtain a new or tweaked
   version of this certificate in the future, simply run certbot
   again. To non-interactively renew *all* of your certificates, run
   "certbot renew"
 - If you like Certbot, please consider supporting our work by:

   Donating to ISRG / Let's Encrypt:   https://letsencrypt.org/donate
   Donating to EFF:                    https://eff.org/donate-le

Add your shiny new certificate to App Service

To secure a custom domain for your web app, Azure requires a private certificate in the PKCS #12 file format. Certbot does not generate this file by default, but you can create it using some of the files it does generate.

Create a private certificate

For this, you'll need:

your server certificate file;
the private key for your certificate;
the intermediate certificate from Let's Encrypt CA.

All those files can be found at /etc/letsencrypt/live/yourdomain.com/, and you can simply run the following commands to create your private certificate:

# create a staging area
$ mkdir /tmp/sandbox -p
$ cd /tmp/sandbox

# copy the needed files over
$ SOURCE=/etc/letsencrypt/live/yourdomain.com
$ sudo cp $SOURCE/{cert.pem,privkey.pem,chain.pem} .

# make the files your own
# assuming your username is ope...
$ sudo chown ope *.pem

# finally, create the private certificate,
# saving it to "certificate.pfx"
$ openssl pkcs12 -export -out certificate.pfx -inkey privkey.pem -in cert.pem -certfile chain.pem

That last command asks you to enter an export password. Please make note of that password since you'll need it when uploading your private certificate on Azure.

Upload the private certificate

From your Azure portal, navigate to your App Service web app and click on the "Custom domains" menu item. In the page that comes up, find the row that contains the custom domain you added and click "Add binding" under the "SSL Binding" column.

In the sidebar that comes up, click "Upload PFX Certificate"

Within the form that's displayed next, select the certificate.pfx file you created, and enter the password you chose.

Click "Upload" to proceed. The next screen should look like this:

Click "Add Binding" once you've selected the relevant options.

That's it! Once the deployment is complete on Azure, you can now navigate to your web app, via your custom domain, using HTTPS.

Clean up

You can't subsequently download your private certificate from Azure App Service, so you might want to store the local copy somewhere other than the system temp directory:

$ cp /tmp/sandbox/certificate.pfx /path/to/dir/

Once your private certificate is safe, you may clear out the sandbox:

$ rm /tmp/sandbox/ -R

Consider turning on "HTTPS Only"

Azure App Service has a little handy feature, called HTTPS Only, that helps redirect all of your app's HTTP traffic to HTTPS.

That makes sure that any client communication with your app is encrypted, and visitors aren't scared away with "Connection not secure" messages from their browsers.

To turn this on, head on to your App Service within the Azure portal, and click on the TLS/SSL settings menu item. You'll find the option there under "Protocol Settings".

Do you (re)arrange your class methods? Why?

Ope Adeyomoye — Thu, 21 Sep 2017 16:31:20 +0000

Lots of (open-source) libraries I go through seem to (re)arrange the methods of member classes in a specific manner e.g. such that any class methods that are to be used by other methods within that class are defined first.

For example:

<?php
class Dispatcher
{
    public function isDispatchable()
    {
        $number = rand(0, 200);

        return ($number < 100) ? true : false;
    }

    public function dispatch()
    {
        if ($this->isDispatchable()) {
            // implementation goes here...
        }
    }
}

Here, isDispatchable() is defined before the method that uses it.

I generally just append new methods to the end of the class whether or not the other methods that use it are above or below. Should I be sent north of the wall?

What do you do?

What are the caveats of using global functions and/or classes with all-static methods?

Ope Adeyomoye — Mon, 19 Jun 2017 23:31:46 +0000

Within the last one year of my three-year journey into web development (on the LAMP stack), I've seen a lot of articles, blog posts etc., where programmers all but liken using global functions and static methods to deploying a nuclear warhead aimed at the server(s) where your application is hosted, but (most of them) without really explaining why that may be the case.

I don't have a CS background (yet), and I just saw another such post some 20 minutes ago so I was wondering whether we could shed some light on this topic here on dev.