DEV Community: SimpleLogin

Why we left AWS

Nguyen Kim Son — Wed, 19 Feb 2020 03:29:21 +0000

I've always been using AWS for hosting from simple prototypes to critical B2B systems. Thanks to its incredible catalog of products, almost all needs are covered.

So naturally the first version of SimpleLogin is hosted on AWS. And as we are based in Paris, the Paris data center is picked for the proximity.

For past adventures, I mostly use third-party email delivery services like Postmark, SendGrid, SES, etc. Unfortunately their pricing models are based on the number of emails, which are not compatible with the unlimited forwards/sends that SimpleLogin offers. In addition, we want SimpleLogin to be easily self-hosted and its components fit on a single server. For these reasons, we decide to run our MTA (Mail Transfer Agent) on EC2 directly.

I naively believed that would work as AWS is after all a VPS hosting service and everything can be run on EC2. As it turns out, we ended up spending way too much time and effort to have our EC2 instances handle email delivery correctly:

Setting up PTR (or rDNS) record on AWS is only achievable via a request ticket and requires several exchanges. In comparison, on UpCloud (our current cloud provider) this could be done directly on the dashboard.
AWS Elastic IP addresses have a bad reputation. We tried to whitelist these IPs but some RBL (Realtime Blacklist) just take forever. And their UX/UI is terrible. We needed to move fast and I feel this mundane task is slowing us down. After attempts to whitelist some IPs, we tested other, newer AWS data centers hoping for better results. Unfortunately, all Elastic IPs we tried were blacklisted by several RBL.
AWS suddenly decided to block our port 25 claiming our email server had become an open relay which was simply not the case. Fortunately that was before the beta so only we were affected. It would be a catastrophe if this happened to our users. We speculate that AWS wants to push for using their SES (Simple Email Service). SES is a nice service but as explained earlier, it is not compatible with our goals. SES is used by some of our self-hosting users though. There's a section in our self-hosting doc that shows how to plug SES into SimpleLogin.

By our experience, AWS doesn’t have in place a good enough mechanism to stop spammers from using their Elastic IPs, leading to their bad network reputation.

It's time to move

Because of the earlier difficulties, we took a step-back and analyzed our architecture to see if it's really dependent on AWS:

we used RDS to manage the database. RDS is a solid service that saves us from database maintenance stuffs like backups or patching. Its replication is also a killer feature. However SimpleLogin doesn't use the database that much: we basically just need to get the mailbox associated with an alias in order to forward the emails and that's about all. A SQLite database might just as well do the job.
we used CloudWatch for monitoring and log management and CloudWatch is a very good solution to centralize and manage logs. Its pricing is also very attractive. However we don't have to be in AWS to use CloudWatch. As the logs are sent asynchronously, using CloudWatch from another cloud doesn't affect performance. In addition some new log services are quite promising and we'd love to give them a try.
we used S3 to upload files, at the time of writing only for user profile pictures. Writing to S3 is not frequent so same as for CloudWatch, we can use S3 from another cloud. Both S3 and Cloudwatch are disabled when self-hosting SimpleLogin so all components still fit on a single server.

So we decided it’s maybe better to make SimpleLogin cloud-agnostic and we'll just manage the cloud servers ourself. That opens several advantages:

We could experience first-hand the difficulties of self-hosting SimpleLogin, otherwise speaking "eat your own dog food".
We could set up a true redundancy mechanism with SimpleLogin deployed on 2 (or more) separate cloud providers.
This point is not really important but it's just so refreshing to use a simple UI rather than the complex AWS Console.

We studied some popular options like DigitalOcean, OVH (OVH is very popular in France), Linode, etc and decided to give UpCloud a serious try due to several reasons:

They came highly recommended by our friend who has more than 100 cloud servers including some email servers on UpCloud and he seems to be pretty happy with their quality & support.
Their cloud servers are not throttled and able to achieve full performance. We haven't done any benchmark but with the same configuration, we feel UpCloud servers are indeed faster than EC2 ones.
Port 25 is not open by default and unlocking it requires a careful examination which helps to maintain the network reputation.

We started by moving our staging environment from AWS to UpCloud. The hardest part was to replace RDS. We decided to take on managing our database ourself using Docker along with some monitoring and backup scripts. Other components were easy to move as they were already based on Docker.

After extensively testing the staging environment we took the plunge to migrate the rest of our cloud environment. Our entire infrastructure is now running on UpCloud. Despite our cautious expectations that the migration would be a rough journey, in the end, the move was smooth and downtime less than 10 minutes. After deploying all components on UpCloud, the longest step was actually just waiting for the DNS changes to propagate.

Now our service has run on UpCloud for some time and our users report having much better success with email delivery. Time will tell, but so far we are pretty happy with UpCloud.

Our next step is to deploy SimpleLogin on another cloud provider for redundancy. Any recommendation is welcome!

Originally posted on https://simplelogin.io/blog/we-left-aws/

Looking for beta testers for open-source email alias service

Nguyen Kim Son — Fri, 20 Dec 2019 21:22:14 +0000

Hi all!

We are building the first open-source email alias and identity provider service, called SimpleLogin

It works in a similar way to other email alias solution (spamex, mailcare, e4ward, etc) with Postfix as MTA and Python script to handle the email forwarding AND backwarding (we don't know how to call it yet, any idea here?): basically an alias can both receive and send emails.

The code source for both the server and clients (libraries, browser extension) is available on our Github at https://github.com/simple-login/, feel free to check it out! We spent quite some time on the self-hosting instructions, if you have your own server, would really appreciate if you can try it!

Please let us know if you have any questions/feedbacks/critics.
Thanks!

Do you prefer one-time fee or subscription?

Nguyen Kim Son — Sun, 10 Nov 2019 21:22:01 +0000

Currently working on the pricing for my SaaS startup, I wonder about which pricing model to apply. It seems that almost all SaaS use subscription billing nowadays and I kind of miss the old day when we can buy a software just once.

Would like to hear what do you guys think, do you prefer one-time fee or subscription billing for a SaaS product?

If you care about user privacy, do NOT use Facebook JS SDK

Nguyen Kim Son — Sun, 03 Nov 2019 08:19:19 +0000

Social Login buttons like the ubiquitous Login with Facebook/Google/Twitter/... button is convenient for users as they don't have to go through a lengthy registration process and create yet another username/password. And without a proper password manager (which probably 99% users don't use), they tend to reuse the same password which is bad in terms of security!

However behind the scene, some SDKs (I'm looking at you Facebook!) inject an iframe in your website to display the Continue as {MyName} or Login with Facebook button. Loading this iframe allows Facebook to know that this specific user is currently on your website. Facebook therefore knows about user browsing behaviour without user's explicit consent. If more and more websites adopt Facebook SDK then Facebook would potentially have user's full browsing history! And as in "With great power comes great responsibility", it's part of our job as developers to protect users privacy even when they don't ask for.

Loading this iframe allows Facebook to know that this specific user is currently on your website

The iframe is actually injected in a second script loaded by the https://connect.facebook.net/en_US/sdk.js:

So what should we do to provide this Login with Facebook button to our users? The good news is this is actually easy as Facebook implements OAuth2/OpenID standard so you can use any OAuth2/OpenID library to add the Facebook login button. You can also add other login providers like Google, Github, Apple ... at the same time as those are also OAuth2/OpenID-compliant.

Here are some ressources to implement OAuth2/OpenID in your app for different languages/frameworks:

JS: hello.js, jso, oidc-client-js. oidc-client-js is used to create some OAuth2/OpenID libraries for frameworks like React, VueJS, Angular, Aurelia as listed on https://github.com/IdentityModel/oidc-client-js/wiki
Python: Requests-OAuthlib, Authlib, Python Social Auth
NodeJS: PassportJS, openid-client.

If you happen to use Flask (Python), I have written an article on dev.to on how to implement OAuth2/OpenID into a Flask application: https://dev.to/simplelogin/create-a-flask-application-with-sso-login-f9m

If you really need Facebook SDK, please ask user consent before loading the SDK or only load the SDK when user clicks on the Login with Facebook button.

Update 1: turns out that Google also uses this practice, more info can be found on https://news.ycombinator.com/item?id=21429482

There are better alternatives to Password Manager

Nguyen Kim Son — Wed, 18 Sep 2019 21:36:53 +0000

Re-using the same password for different websites is bad in terms of security as if a hacker got his hand on a website's database, he/she will have access to your other accounts.

But generating a different password for each website and remembering them is impossible for a human being 😅. That's why Password Managers like LastPass, Dashlane, 1Password, etc are created. Their principle is simple: there's a master password that allows you to manage all other passwords (should we call the other ones slave passwords then 😜?). As loosing this master password will open the port to all our secrets, each password manager has their own multi-factor authentication (MFA) to protect it, ranging from one-time password (TOTP) to printing a secret key that you bring with you all the time.

These tools are gaining more popularity now that users are more and more concerned with privacy but these users are still the minority. One of the reasons is because of the difficult and unusual setup process, especially on phones. But the good news is that now Google and Apple have integrated their own password managers inside Chrome and iPhone/Mac, making the Password Manager concept more accessible to the general public.

So all good right? Not exactly because Password Manager is only half the solution to the security issue. Let me explain.

There are usually two parts to login: the username/email and password. Password Manager only protects the password and not the email. Loosing emails has a less catastrophic effect than the password but if leaked, it can lead to the following consequences:

unsolicited emails, aka spams
social hack: knowing you are on some websites would provide enough information for a sophisticated social hack.

So what is the real solution? For me the solution to both privacy and security is to have different personas online: one for professional work (e.g. Linkedin), one for friends & family (Facebook), one for selfies (Instagram 😄), one for passion (travel, football, etc). These personas are totally independent and knowing one would not reveal the others. The first step to this ideal world is to have different emails and passwords for each website.

Apple has understood that and released the Sign in with Apple button earlier this year. SimpleLogin also works on this challenge by starting with the emails: user can create random email-alias that protects their true personal email. But email is only the first step, next would be other personal information like age, gender, phone number, address, etc. (Disclaimer: I happen to be SimpleLogin co-founder.)

There's also no setup for these SSO buttons: no more additional app to install on the phone and the master password is usually already handled by the browser or the OS directly.

But the challenge is now adoption. Without developers adopting these alternatives and insist staying with the classic username/password, users still need to create their password or use their Password Managers. So make sure to ease your users's life by implementing one of those Social Login buttons 🙏.

Please let username/password rest in peace ⚰️.

Below are some tutorials for adding those social login buttons in different framework/language:

Why you shouldn't create your own authentication system

Nguyen Kim Son — Fri, 13 Sep 2019 18:34:58 +0000

Implementing correctly an authentication system is hard.

If you start creating your website/application now, please use a third party authentication. Third party authentication can be social login (e.g. the ubiquitous Login with Facebook button) or identity management tools like Auth0 or Okta.

It's not just about storing username/password in the database. In a standard web application, an authentication system needs to:

store password hash instead of password in cleartext. And each user should have their own salt. And the hash function should be expensive to compute. For all this, you would need a very good understanding on Rainbow tables, Bcrypt, Hash algorithms and salts.
have email verification and reset-password features. For that you might need to generate and store a temporary, short-lived token that is used to activate an account or to reset password. And this is the simple part. Making sure that your email doesn't fall into the Spam folder is much harder.

On the front-end side, the app needs to have a decent UI: a login form that at least validates the email and password, a sign-up form, a reset-password form. Not to mention modern authentication expects support for MFA and soon (hopefully) WebAuthn.

More importantly, your users don't want to go through a lengthy registration process and create yet another username/password. Without a proper password manager (which probably 99% users don't use), they tend to reuse the same password which is bad in terms of security!

So why choosing the hard path and face the risk of password leaks, database hackings and above all, inferior user experience? Of course some applications need to have their own authentication system (banking app is an example but that's also changing with PSD2) but they are rather minority.

So which 3rd-party verification should my app use?

This really depends on your app. If getting user's Facebook feed can be a big plus to your app, then you should probably go with Login with Facebook. If having access to user's Twitter feed is valuable, then Login with Twitter is more appropriate. If your app only requires user basic information like email, name, avatar picture then I would suggest Login with SimpleLogin, a developer-friendly login solution. Disclaimer: I happen to be SimpleLogin co-founder so this advice is obviously subjective 😅.

We should all stop requiring users to choose a username and password. There are better alternatives.

Please let username/password rest in peace ⚰️.

Create a Flask application with SSO login

Nguyen Kim Son — Fri, 13 Sep 2019 00:28:01 +0000

It's often needed to have some sort of login functionality in an app so users can save data or create their own profiles. Or maybe only authenticated users can have access to reserved content. In a modern app, users expect to have standard login-related features like email verification, password reset, multi-factor authentication, etc. These features, though necessary, are not easy to get right and usually not the app's main business.

On the user side, they don't want to go through the lengthy registration process neither as they need to create and remember yet another email/password. Without a proper password manager, users tend to reuse the same password which is terrible in terms of security.

SSO (Single sign-on), mostly known to the public by the everywhere Login with Facebook/Google/Twitter buttons, was invented as a solution for this issue. For users, they don't have to go through the painful registration process: one click is all it needs. For developers, removing friction for users is always a huge win and in addition, all login-related features are now delegated to the Identity provider (i.e. Facebook/Google/Twitter). Your app simply trusts the Identity provider of doing its job of verifying user identity.

SSO is usually powered by OIDC (OpenId Connect) or SAML protocol. SAML is used mostly in enterprise application. OIDC is built on top of OAuth2 and used by social identity providers like Facebook, Google, etc. In this post, we'll focus on the OIDC/OAuth2 protocol.

This post presents a step-by-step guide to add a SSO Login button into a Flask application with SimpleLogin and Facebook as Identity provider. This can be done without using any external library but in order not to worry too much about the OAuth details, we'll use Requests-OAuthlib, a library to integrate OAuth providers. If you are interested in implementing a SSO login from scratch, please check out Implement SSO Login the raw way.

At the end of this article, you should have a Flask app that has the following pages:

Home page: that only has the login button
User information page: upon successful login, the user will be able to see information such as name, email, avatar.

All steps of this tutorial can be found on flask-social-login-example repository.

A demo is also available at https://nguyenkims-flask-social-login-example.glitch.me, feel free to remix the code on Glitch 😉.

Step 1: Bootstrap Flask app

Install flask and Requests-OAuthlib. You can also use virtualenv or pipenv to isolate the environment.

pip install flask requests_oauthlib

Create app.py and the route that displays a login button on the home page:



import flask

app = flask.Flask(__name__)

@app.route("/")
def index():
    return """
    <a href="/login">Login</a>
    """

if __name__ == '__main__':
    app.run(debug=True)

Let's run this app and verify everything is working well:

python app.py

You should see this page when opening http://localhost:5000. The full code is on step1.py

Step 2: Identity provider credential

There are currently hundreds (if not thousands) identity providers with the most popular ones being Facebook, Google, Github, Instagram, etc. For this post, SimpleLogin is chosen because of its developer-friendliness. The same code will work with any OAuth2 identity provider (Facebook, Google, etc) though. Disclaimer: I happen to be SimpleLogin co-founder so this choice is obviously subjective.

As going through the setup of Facebook, Google, Twitter login is a bit complex (everyone uses Google Cloud Console can feel the pain 😅) and requires additional steps that are beyond the scope of this post like setting up SSL, choosing right scopes, etc. the section Login with Facebook is rather provided as an appendix at the end of the post.

Please head to SimpleLogin and create an account if you do not have one already, then create a new app in Developer tab.

On app detail page, please copy your AppID and AppSecret and save them into variable environment. In OAuth terminology, client actually means a third-party app, i.e. your app. We can put these values directly in the code but it's a good practice to save credentials into variable environments. This is also the third factor in the The Twelve Factors.



export CLIENT_ID={your AppID}
export CLIENT_SECRET={your AppSecret}

In app.py please add these lines on top of the file to get client id and client secret



import os
CLIENT_ID = os.environ.get("CLIENT_ID")
CLIENT_SECRET = os.environ.get("CLIENT_SECRET")

Please also add these OAuth URLs on the top of app.py that are going to be used in the next step. They can also be copied on the OAuth endpoints page.



AUTHORIZATION_BASE_URL = "https://app.simplelogin.io/oauth2/authorize"
TOKEN_URL = "https://app.simplelogin.io/oauth2/token"
USERINFO_URL = "https://app.simplelogin.io/oauth2/userinfo"

As we don't want to worry about setting up SSL now, let's tell Requests-OAuthlib that it's OK to use plain HTTP:



# This allows us to use a plain HTTP callback
os.environ["OAUTHLIB_INSECURE_TRANSPORT"] = "1"

As usual, the code for this step is on step2.py

Step 3: Login redirection

When a user clicks on the login button:

The user will be redirected to the identity login provider authorization page asking whether user wants to share their information with your app.
Upon user approval, they will be then redirected back to a page on your app along with a code in the URL that your app will use to exchange for an access token that allows you later to get user information from the service provider.

We need therefore two routes: a login route that redirects the user to the identity provider and a callback route that receives the code and exchanges for access token. The callback route is also responsible for displaying user information.



@app.route("/login")
def login():
    simplelogin = requests_oauthlib.OAuth2Session(
        CLIENT_ID, redirect_uri="http://localhost:5000/callback"
    )
    authorization_url, _ = simplelogin.authorization_url(AUTHORIZATION_BASE_URL)

    return flask.redirect(authorization_url)


@app.route("/callback")
def callback():
    simplelogin = requests_oauthlib.OAuth2Session(CLIENT_ID)
    simplelogin.fetch_token(
        TOKEN_URL, client_secret=CLIENT_SECRET, authorization_response=flask.request.url
    )

    user_info = simplelogin.get(USERINFO_URL).json()
    return f"""
    User information: <br>
    Name: {user_info["name"]} <br>
    Email: {user_info["email"]} <br>
    Avatar <img src="{user_info.get('avatar_url')}"> <br>
    <a href="/">Home</a>
    """

Clicking on Login button should bring you through the following flow. The full code can be found on Github - step3.py

Conclusion

Congratulations 🎉 you have successfully integrated SSO login into a Flask app!

For the sake of simplicity, this tutorial doesn't mention other OAuth concepts like scope and state, important to defend against *Cross Site Request Forgery * attack. You would also probably need to store the user info in a database which is not covered in this article.

The app also needs to be served on https on production, which can be quite easily done today with Let’s Encrypt.

Happy OAuthing!

Appendix: Login with Facebook

As promised earlier, please find below the steps to integrate Login with Facebook button 🙂. Apart from a quite sophisticated UI, the hardest part about integrating Facebook might be finding a way to serve your web app on https locally as the new version of Facebook SDK doesn't allow local plain HTTP. I recommend using Ngrok, a free tool to have a quick https URL.

Step 1: Create a Facebook app:

Please head to https://developers.facebook.com and create a new app

Then choose "Integration Facebook Login" on the next screen

Step 2: Facebook OAuth credential

Click on "Settings/Basic" on the left and copy the App ID and App Secret, they are actually OAuth client-id and client-secret.

Update the client-id and client-secret



export FB_CLIENT_ID={your facebook AppId}
export FB_CLIENT_SECRET={your facebook AppSecret}

Update the AUTHORIZATION_BASE_URL and TOKEN_URL:



FB_AUTHORIZATION_BASE_URL = "https://www.facebook.com/dialog/oauth"
FB_TOKEN_URL = "https://graph.facebook.com/oauth/access_token"

The home page



@app.route("/")
def index():
    return """
    <a href="/fb-login">Login with Facebook</a>
    """

Step 3: Login and callback endpoints

If the app is served behind ngrok using ngrok http 5000 command, we need to set the current url to the ngrok url



# Your ngrok url, obtained after running "ngrok http 5000"
URL = "https://abcdefgh.ngrok.io"

Please make sure to add the url https://abcdefgh.ngrok.io/fb-callback to your Facebook Login/Settings, Valid OAuth Redirect URIs setting:

In order to have access to a user email, you need to add email into scope



FB_SCOPE = ["email"]

@app.route("/fb-login")
def login():
    facebook = requests_oauthlib.OAuth2Session(
        FB_CLIENT_ID, redirect_uri=URL + "/fb-callback", scope=FB_SCOPE
    )
    authorization_url, _ = facebook.authorization_url(FB_AUTHORIZATION_BASE_URL)

    return flask.redirect(authorization_url)

The callback route is a bit more complex as Facebook requires a compliance fix:



from requests_oauthlib.compliance_fixes import facebook_compliance_fix

@app.route("/fb-callback")
def callback():
    facebook = requests_oauthlib.OAuth2Session(
        FB_CLIENT_ID, scope=FB_SCOPE, redirect_uri=URL + "/fb-callback"
    )

    # we need to apply a fix for Facebook here
    facebook = facebook_compliance_fix(facebook)

    facebook.fetch_token(
        FB_TOKEN_URL,
        client_secret=FB_CLIENT_SECRET,
        authorization_response=flask.request.url,
    )

    # Fetch a protected resource, i.e. user profile, via Graph API

    facebook_user_data = facebook.get(
        "https://graph.facebook.com/me?fields=id,name,email,picture{url}"
    ).json()

    email = facebook_user_data["email"]
    name = facebook_user_data["name"]
    picture_url = facebook_user_data.get("picture", {}).get("data", {}).get("url")

    return f"""
    User information: <br>
    Name: {name} <br>
    Email: {email} <br>
    Avatar <img src="{picture_url}"> <br>
    <a href="/">Home</a>
    """

Now when clicking on Login with Facebook, you should be able to go through the whole flow.

The full code is on facebook.py

Integrating Login with Google/Twitter/... is quite similar. Please let me know in the comment if you would like to have similar sections for these social login providers!

Python Logging: An In-Depth Tutorial

Nguyen Kim Son — Fri, 26 Jul 2019 20:05:01 +0000

As applications become more complex, having good logs can be very useful, not only when debugging but also to provide insight for application issues/performance. Logging is also one of the factor in the famous The twelve-factor app.

The Python standard library comes with a logging module that provides most of the basic logging features. By setting it up correctly, a log message can bring a lot of useful information about when and where the log is fired as well as the log context, such as the running process/thread.

Despite the advantages, the logging module is often overlooked as it takes some time to set up properly. The official doc at https://docs.python.org/3/library/logging.html, although complete, does not give best practices or highlight some logging surprises.

This Python logging tutorial is not meant to be a complete document on the logging module but rather a getting started guide that introduces some logging concepts as well as some gotchas to watch out for. The post will end with best practices.

Please note that all code snippets in the post suppose that you have already imported the logging module:

import logging

Concepts for Python Logging

This section gives an overview of some concepts that are often encountered in the logging module.

Levels

The log level corresponds to the importance a log is given: an error log should be more urgent then than the warn log, whereas a debug log should only be enabled when debugging the application.

There are six log levels in Python; each level is associated with an integer that indicates the log severity: NOTSET=0, DEBUG=10, INFO=20, WARN=30, ERROR=40, CRITICAL=50.

Formatter

The log formatter enriches a log message by adding context information to it. It can be useful to know when the log is sent, where (Python file, line number, method, etc.), and additional context such as the thread and process id (can be extremely useful when debugging a multi-threaded application).

For example, when a log hello world is sent through this log formatter:

"%(asctime)s — %(name)s — %(levelname)s — %(funcName)s:%(lineno)d — %(message)s"

it will become

2018-02-07 19:47:41,864 - a.b.c - WARNING - <module>:1 - hello world

Handler

The log handler is the component that effectively writes/displays a log: it can display the log in the console via StreamHandler, write into a file via FileHandler, or even send you an email via SMTPHandler, etc.

Each log handler has 2 important fields:

A formatter which adds context information to a log.
A log level that filters out logs whose levels are inferior. For example a log handler with the INFO level will not handle DEBUG logs.

The standard library provides a handful of handlers that should be enough for common use cases: https://docs.python.org/3/library/logging.handlers.html#module-logging.handlers. The most common ones are StreamHandler and FileHandler:

console_handler = logging.StreamHandler()
file_handler = logging.FileHandler("filename")

Logger

Logger is the object that we will interact with the most and which is also the most complex concept. A new logger can be obtained by:

toto_logger = logging.getLogger("toto")

A logger has three main fields:

Propagate: Decides whether a log should be propagated to the logger’s parent. By default, its value is True.
Level: Like the handler level, the logger level is used to filter out less important logs. Except, unlike the log handler, the level is only checked at the child logger; once the log is propagated to its parents, the level will NOT be checked. This is rather an un-intuitive behavior.
Handlers: The list of handlers that a log will be sent to when it arrives to a logger. This allows a flexible log handling—for example, you can have a file log handler that logs all DEBUG logs and an email log handler that will only be used for CRITICAL logs. In this regard, the logger-handler relationship is similar to a publisher-consumer one: A log will be broadcasted to all handlers once it passes the logger level check.

A logger is unique by name, meaning that if a logger with the name toto has been created, the consequent calls of logging.getLogger("toto") will return the same object:

assert id(logging.getLogger("toto")) == id(logging.getLogger("toto"))

As you might have guessed, loggers have a hierarchy. On top of the hierarchy is the root logger, which can be accessed via logging.root. This logger is called when a method is called directly on logging module, e.g. logging.debug(). By default, the root log level is WARN, so every log with lower level , for example logging.info("info"), will be ignored.

Another particularity of the root logger is that its default handler will be created the first time a log with a level greater than WARN is logged. Using the root logger directly or indirectly via methods like logging.debug() is generally not recommended.

By default, when a new logger is created, its parent will be set to the root logger:

lab = logging.getLogger("a.b")
assert lab.parent == logging.root # lab's parent is indeed the root logger

However, the logger uses the dot notation, meaning that a logger with the name a.b will be the child of the logger a. However, this is only true if the logger a has been created, otherwise ab parent is still the root logger.

la = logging.getLogger("a")
assert lab.parent == la # lab's parent is now la instead of root

When a logger decides whether a log should pass according to the level check (e.g., if the log level is lower than logger level, the log will be ignored), it uses its effective level instead of the actual level, i.e. logger.level. The effective level is the same as logger level if the level is NOT NOTSET, i.e., all the values from DEBUG up to CRITICAL; however, if the logger level is NOTSET, then the effective level will be the first ancestor level that has a non-NOTSET level.

By default, a new logger has the NOTSET level, and as the root logger has a WARN level, the logger’s effective level will be WARN. So even if a new logger has some handlers attached, these handlers will not be called unless the log level exceeds WARN:

toto_logger = logging.getLogger("toto")
assert toto_logger.level == logging.NOTSET # new logger has NOTSET level
assert toto_logger.getEffectiveLevel() == logging.WARN # and its effective level is the root logger level, i.e. WARN

# attach a console handler to toto_logger
console_handler = logging.StreamHandler()
toto_logger.addHandler(console_handler)
toto_logger.debug("debug") # nothing is displayed as the log level DEBUG is smaller than toto effective level
toto_logger.setLevel(logging.DEBUG)
toto_logger.debug("debug message") # now you should see "debug message" on screen

By default, the logger level will be used to decide if a log passes: If the log level is lower than logger level, the log will be ignored.

Python Logging Best Practices

The logging module is indeed very handy, but it contains some quirks that can cause long hours of headache for even the best Python developers. Here are the best practices for using this module in my opinion:

Configure the root logger but never use it in your code, e.g., never call a function like logging.info(), which calls the root logger behind the scene. Configuring the root logger is useful if you want to catch error messages from used libraries.
To use the logging, make sure to create a new logger by using logging.getLogger(logger name). I usually use __name__ as the logger name for individual module or a static name for a whole app/lib, but anything can be used as long as it is consistent. To add more handlers, I usually have a method that returns a logger (you can find the gist on https://gist.github.com/nguyenkims/e92df0f8bd49973f0c94bddf36ed7fd0).

import logging
import sys
from logging.handlers import TimedRotatingFileHandler
FORMATTER = logging.Formatter("%(asctime)s — %(name)s — %(levelname)s — %(message)s")
LOG_FILE = "my_app.log"

def get_console_handler():
   console_handler = logging.StreamHandler(sys.stdout)
   console_handler.setFormatter(FORMATTER)
   return console_handler

def get_file_handler():
   file_handler = TimedRotatingFileHandler(LOG_FILE, when='midnight')
   file_handler.setFormatter(FORMATTER)
   return file_handler

def get_logger(logger_name):
   logger = logging.getLogger(logger_name)
   logger.setLevel(logging.DEBUG) # better to have too much log than not enough
   logger.addHandler(get_console_handler())
   logger.addHandler(get_file_handler())
   # with this pattern, it's rarely necessary to propagate the error up to parent
   logger.propagate = False
   return logger

After you can create a new logger and use it:

my_logger = get_logger("my module name")
my_logger.debug("a debug message")

Use RotatingFileHandler classes, such as the TimedRotatingFileHandler used in the example instead of FileHandler, as it will rotate the file for you automatically when the file reaches a size limit or do it every day.
Use tools like Sentry, Airbrake, Raygun, etc., to catch error logs automatically for you. This is especially useful in the context of a web app, where the log can be very verbose and error logs can get lost easily. Another advantage of using these tools is that you can get details about variable values in the error so you can know what URL triggers the error, which user is concerned, etc.

Making sure logging works correctly should be one of the first things to do when setting up a new project as it could save countless hours of debugging in the future.