Posts

Complaint feedback loop address header (CFBL-Address)

Image
In the realm of email communication, whether you rely on an Email Service Provider (#ESP) or manage your own email infrastructure, feedback loops are instrumental in preserving sender reputation and guaranteeing the delivery of authentic messages. Nonetheless, setting up and overseeing feedback loops can frequently become a cumbersome and time-consuming task. This is precisely where CFBL-Address Header steps in—a pioneering solution that streamlines this entire process. Let’s delve into the significance of CFBL-Address Header, understanding its functionality, and why it stands as a crucial tool for both email senders and providers. What is CFBL-Address Header? The CFBL Address header, outlined in RFC 9477, empowers email authors to designate the Complaint Feedback Loop (CFBL) address directly within the message header. This designated address serves as the primary point of contact for receiving feedback from mailbox providers regarding email complaints. How Does it Work? Traditionally,

Strengthening Your Web Apps: A Guide to HTTP Security Headers

Image
  There is a certain set of standard HTTP headers that every website should ideally set to provide a basic level of security. This note discusses such headers and how to set them on sites deployed in Netlify. Common security headers First, let’s consider basic HTTP headers - they are common to all requests and provide a basic level of security. The Content-Security-Policy header helps protect your website from cross-site scripting attacks by providing a list of approved content. This header allows you to prohibit the use of content that does not pass the rules or should not be used as content. Setting this header may seem complicated, so if you want to delve into the topic, visit the official website. Example usage: Content-Security-Policy: default-src 'https://example.com'; script-src 'unsafe-inline' 'https://example.com'; style-src 'unsafe-inline' 'https://example.com'; object-src 'none' The X-Frame-Options header tells the brow

UserWarning: NumPy was imported from a Python sub-interpreter

Image
  Whe you get the error message like: [Fri Feb 09 14 : 44 : 16.693488 2024 ] [wsgi:error] [pid 13012 :tid 281472973443264 ] [remote 81.82 . 223.150 : 61164 ] /usr/local/venvs/django_ner/lib/python3. 10 /site-packages/thinc/__init__.py: 2 : UserWarning: NumPy was imported from a Python sub-interpreter but NumPy does not properly support sub-interpreters. This will likely work for most users but might cause hard to track down issues or subtle bugs. A common user of the rare sub-interpreter feature is wsgi which also allows single-interpreter mode. [Fri Feb 09 14 : 44 : 16.693987 2024 ] [wsgi:error] [pid 13012 :tid 281472973443264 ] [remote 81.82 . 223.150 : 61164 ] Improvements in the case of bugs are welcome, but is not on the NumPy roadmap, and full support may require significant effort to achieve. [Fri Feb 09 14 : 44 : 16.694006 2024 ] [wsgi:error] [pid 13012 :tid 281472973443264

Colorize your terminal bash prompt by modifying the .bashrc file.

Image
  Go to your  .bashrc  file and remove the comment from the  force_color_prompt  line. vim ~/.bashrc .. # search for force_color_prompt=yes ... # Than source ~/.bashrc

psql: error: connection to server at "localhost" (127.0.0.1), port 5433 failed: ERROR: failed to authenticate with backend using SCRAM DETAIL: valid password not found

Image
ERROR psql: error: connection to server at "localhost" (127.0.0.1), port 5433 failed: ERROR: failed to authenticate with backend using SCRAM DETAIL: valid password not found Since Pgpool-II is a PostgreSQL proxy that works between clients and PostgreSQL servers, the authentication comprises two steps: Authentication between client and Pgpool-II Authentication between Pgpool-II and PostgreSQL servers Starting with Pgpool-II 4.0, Pgpool-II supports scram-sha-256 authentication. scram-sha-256 authentication method is strongly recommended because it is the most secure password-based authentication method. Solution 1 If PostgreSQL servers require  MD5  or  SCRAM  authentication for some user’s authentication but the password for that user is not present in  pool_passwd , then enabling  allow_clear_text_frontend_auth  will allow the  Pgpool-II  to use clear-text-password authentication with user to get the password in plain text form from the user and use it for backend authenticat

ERROR: pid 29754: initializing pool password, failed to open file:"/etc/pgpool2/pool_passwd"

Image
  If you encountered the error: ERROR: pid 29506 : initializing pool password, failed to open file: "/etc/pgpool2/pool_passwd" Than you have to change the owner of the file  pool_passwd  to  postgres : sudo chown -R postgres:postgres /etc/pgpool2/pool_passwd Finally you can run: su - postgres pg_enc -m -k ~/.pgpoolkey -f /etc/pgpool2/pgpool.conf -u vstat -p Related article on: https://dev.smirnov.app/2022/06/psql-error-connection-to-server-failed-to-authenticate-with-backend-using-scram-detail.html

Settings ~/.vimrc

Image
  These settings are commonly used to customize the behavior and appearance of the Vim text editor. They ensure consistent coding style, comfortable text navigation, and useful features during editing. Make sure to adapt these settings according to your preferences and the specific requirements of your projects. set encoding=utf8 > Set encoding to UTF- 8 set paste > Enable paste mode set expandtab > Use spaces instead of tabs for indentation set textwidth= 0 > Disable automatic text wrapping set tabstop= 4 > Number of spaces that a <Tab> in the file counts for set softtabstop= 4 > Number of spaces to use for each step of (auto)indent set shiftwidth= 4 > Number of spaces to use for (auto)indent set smartindent > Enable smart auto-indenting set backspace=indent,eol,start > Allow backspacing over autoindent, line breaks, and start of insert set

SSL: CERTIFICATE_VERIFY_FAILED with Python2.7/3

Image
To enhance flexibility and address specific use cases, modifications will be made to the ssl module instead of consistently relying on  ssl.create_default_context . The updated approach involves checking the  PYTHONHTTPSVERIFY  environment variable upon the module’s initial import in a Python process. The  ssl._create_default_https_context  function will then be configured as follows: If the environment variable is present and set to ‘0’,  ssl._create_default_https_context  will be an alias for ssl._create_unverified_context. Otherwise,  ssl._create_default_https_context  will be an alias for  ssl.create_default_context , adhering to the usual behavior. Here is an example implementation: import os import sys import ssl _https_verify_envvar = 'PYTHONHTTPSVERIFY' def _get_https_context_factory () : if not sys.flags.ignore_environment: config_setting = os.environ.get(_https_verify_envvar) if config_setting == '0' : return ssl._cr