A common task in any popular programming language is the ability to send emails to your users, be it as a password reset or as a contact page submission on a blog just like this one.
The below snippet can be used to accomplish this, just change the variables depending on your use case. It assumes that you have a local SMTP server running on the machine you are running the script on (Postfix for example), however you can also login to another service if you want to send via Gmail or Outlook etc.
You can also add additional properties to the MIME message for extra functionality:
Reply-To: Name <address> to specify who the receiver should send their replies to
Change the Content-type to text/html if you want to use HTML within your message body for styling
With all the focus these days on cybersecurity and the push towards a more secure web, it’s more important than ever to ensure as many users as possible are using the HTTPS version of your site instead of the default HTTP version. Google search results will now rank secure versions better than their variations and some browsers are actively warning users if they are not browsing through HTTPS and there is a password input field on the page for example.
As such, having all of your standard HTTP traffic automatically redirect to their HTTPS equivalent can not only help reassure your visitors, but also potentially increase traffic as a whole. There really aren’t any excuses for not using HTTPS now when Let’s Encrypt is available.
Configuring redirects within your web server of choice is quite trivial. In this post I will focus on Apache, however I am sure the config is equally as straightforward if you are an Nginx user.
The first step is of course to make sure that you have a HTTPS version of your site available to the public. There are a thousand guides online about how to to this so I won’t cover it again here, but in short get a certificiate for your domain from Let’s Encrypt via certbot, create a new VirtualHost within Apache listening on port 443 and enable SSLEngine - pointing to your certificate. At this point your should have two versions of your site available - one through HTTP and one through HTTPS. At the end of this all of the HTTP traffic will be redirected the HTTPS virtual host.
Navigate to your main Apache config file which contains your HTTP virtual host definition. This is normally in /etc/apache2/sites-available and might be called something like 000-default.conf if you haven’t renamed it. If the first line of the file is <VirtualHost *:80> you are in the right place.
Open this file with your favourite text editor (you will need root privileges) and add the following, replacing “your-domain-name” with, of course, your domain name:
# Redirect to HTTPS
Redirect permanent / https://your-domain-name.com/
And that’s it. Run the command sudo service apache2 restart to pick up the changes and then test it out. Navigating to any of your pages through HTTP should be automatically redirected to HTTPS resulting in that nice green padlock in your browser.
In Chrome, when you open a link in a new background tab (e.g middle click), any videos on that page (YouTube etc) will not start to play until you directly visit that tab (bringing it to the foreground). This is is something I make use of quite often, however this behaviour is not the default in Firefox. Thankfully though, due to the great configuration options in Firefox, this can easily be fixed:
Type about:config in the search bar to open up all of the configuration options.
Filter the results by entering autoplay into the search box.
Toggle the preference media.block-autoplay-until-in-foreground to true.
From then on, any videos will not begin until you bring that tab into the foreground. When media is being blocked from playing, a play icon will appear in the tab (similar to the mute button for audio). You can click on this to begin playing without bringing the tab to the foreground.
Similarly to how you can hold shift whilst you right click on a directory within Windows explorer to open a new command prompt at that directory, it is also possible to do the same with the new WSL Bash. This can make it much easier to work with files within explorer from within the WSL as opposed to lengthy cd commands to the relevant mnt.
To add the new context menu item for Bash within explorer, you need to create a new key within the registry and a few new values underneath it:
Open the registry editor by searching for regedit or going through Win+R. You will need admin privileges to open the editor.
(Optional) Backup your registry via File->Export.
Navigate to the key HKEY_CLASSES_ROOT\Directory\Background\shell.
Create a new key called WSL under shell and and another key underneath WSL called command. This should reflect the structure in the cmd key within shell. The newly created structure should be HKEY_CLASSES_ROOT\Directory\Background\shell\WSL\command.
Change the Default value under the WSL key to the value you want to see in the context menu e.g. ‘Bash Prompt Here’.
(Optional) Create a new String value called Icon under the WSL key with a value of %USERPROFILE%\\AppData\\Local\\lxss\\bash.ico. This will make the bash icon appear in the context menu as seen in the screenshot above.
Change the Default value under the command key to cmd.exe /c pushd "%V" && bash.exe.
Exit the editor and test by right clicking the white space within any directory in Windows Explorer.
You should something corresponding to the screenshot. Selecting the new menu item will open up a new WSL Bash prompt starting at the current directory.
Here is the contents of a .reg file you can also use instead of the above. Simply copy the contents into a file with the .reg extension and then double click on it to merge it into your registry.
If you have accidentally committed a password or other sensitive data to your Git repository, make sure to remove it before pushing it to GitHub or making it open source. When working with databases or other external systems, it’s incredibly easy to put a password into a configuration file, commit it and forget about it - only for it to be subsequently completely visible to everyone on the internet thereafter.
Thankfully, there are a few ways to remove private data from your Git repos. The most bare-metal approach would be to use the git-filter-branch command which is able to rewrite your Git history whilst applying filters. It’s a very powerful command and therefore has many configuration options and is quite difficult to use directly.
A much easier solution is to use the BFG Repo Cleaner. This is a separate tool which offers a much faster and simpler method of cleaning your repo of private data or very large files.
To make use of this tool, first make sure you have Java installed and available on the PATH - follow the steps in this post to do so. Then download the .jar file from their site.
Find sensitive data within your repository
If you have a password or other credential that you think you may have accidentally committed into your repo, run the following command to find out. This uses the ‘pickaxe’ option of git log to find revisions in which the number of occurences of a search time has changed.
$ git log -S<password>
From the docs:
-S Look for differences that change the number of occurrences of the specified string (i.e. addition/deletion) in a file.
-G: looks for differences whose added or removed line matches the given regexp, as opposed to -S, which “looks for differences that introduce or remove an instance of string”.
–all: searches over all branches and tags
Remove passwords and private data using BFG
Create a file called passwords.txt, in which place all your passwords or sensitive data.
Run the command $ java -jar bfg.jar --replace-text passwords.txt <your-repo>
More documentation and examples, along with how to remove large files from your repo can found on the BFG project page.
Note: This will completely rewrite your Git history, the hashes or all commits will be re-generated.