I enjoy contributing to open-source, but I’d prefer to keep my passwords to myself! Python is a great glue language for automating tasks, and recently I’ve been using it to log in to my web server using SFTP and automate log analysis, file management, and software updates. The Python scripts I’m working on need to know my login information, but I want to commit them to source control and share them on GitHub so I have to be careful to use a strategy which minimizes risk of inadvertently leaking these secrets onto the internet.
This post explores various options for managing credentials in Python scripts in public repositories. There are many different ways to manage credentials with Python, and I was surprised to learn of some new ones as I was researching this topic. This post reviews the most common options, starting with the most insecure and working its way up to the most highly regarded methods for managing secrets.
You could put a password or API key directly in your python script, but even if you intend to remove it later there’s always a chance you’ll accidentally commit it to source control without realizing it, posing a security risk forever. This method is to be avoided at all costs!
A slightly less terrible idea is to obfuscate plain-text passwords by storing them as base 64 strings. You won’t know the password just by seeing it, but anyone who has the string can easily decode it. Websites like https://www.base64decode.org are useful for this.
If the text file is in the repository directory you should modify .gitignore to ensure it’s not tracked by source source control. There is a risk that you may forget to do this, exposing your credentials online! A better idea may be to place the secrets file outside your repository folder entirely.
💡 There are libraries which make this easier. One example is Python Decouple which implements a lot of this logic gracefully and can even combine settings from multiple files (e.g., .ini vs .env files) for environments that can benefit from more advanced configuration options. See the notes below about helper libraries that environment variables and .env files
⚠️ WARNING: This method is prone to mistakes. Ensure the secrets module is never committed to source control.
Similar to a plain text file not tracked by source control (ideally outside the repository folder entirely), you could store passwords as variables in a Python module then import it.
⚠️ WARNING: This method may store plain text passwords in your command history.
This isn’t a great idea because passwords are seen in plain text in the console and also may be stored in the command history. However, you’re unlikely to accidentally commit passwords to source control.
You could request the user to type their password in the console, but the characters would be visible as they’re typed.
# ⚠️ This code displays the typed passwordpassword =input("Password: ")
Python has a getpass module in its standard library made for prompting the user for passwords as console input. Unlike input(), characters are not visible as the password is typed.
# 👍 This code hides the typed passwordimportgetpasspassword = getpass.getpass('Password: ')
This is an interesting method. It’s fast and simple, but a bit quirky. Downsides are (1) it requires the password to be in the clipboard which may expose it to other programs, (2) it requires installation of a nonstandard library, and (3) it won’t work easily in server environments.
The Tk graphics library is a cross-platform graphical widget toolkit that comes with Python. A login window that collects username and password can be created programmatically and wrapped in a function for easily inclusion in scripts that otherwise don’t have a GUI.
I find this technique particularly useful when the username and password are stored in a password manager.
Downsides of keyrings are (1) it requires a nonstandard library, (2) implementation may be OS-specific, (3) it may not function easily in cloud environments.
pip install keyring
# store the password onceimportkeyringkeyring.set_password("system", "myUsername", "S3CR3T_P455W0RD")
# recall the password at any timeimportkeyringpassword = keyring.get_password("system", "myUsername")
Environment variables are one of the better ways of managing credentials with Python. There are many articles on this topic, including Twilio’s How To Set Environment Variables and Working with Environment Variables in Python. Environment variables are one of the preferred methods of credential management when working with cloud providers.
Be sure to restart your console session after editing environment variables before attempting to read them from within python.
importospassword = os.getenv('demoPassword')
There are many helper libraries such as python-dotenv and Python Decouple which can use local .env files to dynamically set environment variables as your program runs. As noted in previous sections, when storing passwords in plain-text in the file structure of your repository be extremely careful not to commit these files to source control!
Example .env file:
demoPassword2=superSecret
The dotenv package can load .env variables as environment variables when a Python script runs:
python-dotenv reads key-value pairs from a .env file and can set them as environment variables. It helps in the development of applications following the 12-factor principles.
Python Decouple helps you to organize your settings so that you can change parameters without having to redeploy your app.
How do you manage credentials in Python? If you wish to share feedback or a creative method you use that I haven’t discussed above, send me an email and I can include your suggestions in this document.
WSPR (Weak Signal Propagation Reporter) is a protocol for weak-signal radio communication. Transmissions encode a station’s callsign, location (grid square), and transmitter power into a frequency-shift-keyed (FSK) signal that hops between 4 frequencies to send 162 tones in just under two minutes. Signals can be decoded with S/N as low as −34 dB! WSJT-X, the most commonly-used decoding software, reports decoded signals to wsprnet.org so propagation can be assessed all over the world.
WsprSharp is a WSPR encoding library implemented in C#. I created this library learn more about the WSPR protocol. I also made a web application (using Blazor WebAssembly) to make it easy to generate WSPR transmissions online: WSPR Code Generator
In C#, you can document your code using XML directly before code blocks. This XML documentation is used by Visual Studio to display tooltips and provide autocomplete suggestions.
/// <summary>/// This method performs an important function./// </summary>publicvoid MyMethod() {}
To enable automatic generation of XML documentation on every build, add the following to your csproj file:
However, XML documentation is not actually metadata, so it is not available in the compiled assembly. In this post I’ll show how you can use System.Reflection to gather information about methods and combine it with documentation from an XML file read with System.Xml.Linq.XDocument.
I find this useful for writing code which automatically generates documentation. Reflection alone cannot provide comments, and XML documentation alone cannot provide parameter names (just their types). By combining reflection with XML documentation, we can more completely describe methods in C# programs.
⚠️ WARNING: These code examples are intentionally simple. They only demonstrate how to read summary comments from XML documentation for methods found using reflection. Additional functionality can be added as needed, and my intent here is to provide a simple starting point rather than overwhelmingly complex examples that support all features and corner cases.
💡 Source code can be downloaded at the bottom of this article
✔️ The “hack” described on this page is aimed at overcoming limitations of partially-documented XML. A better solution is to fully document your code, in which case the XML document is self-sufficient. The primary goal of these efforts is to use XML documentation where it is present, but use Reflection to fill in the blanks about methods which are undocumented or only partially documented. Perhaps a better strategy would be to have a fully documented code base, with an XML file containing <summary>, <returns>, and <param> for every parameter. Tests can ensure this is and remains the case.
There are some nuances here you might not expect, especially related to arrays, generics, and nullables. Let’s start with a demo class with documented summaries. Keep in mind that the goal of this project is to help use Reflection to fill in the blanks about undocumented or partially-documented code, so this example will only add a <summary> but no <param> descriptions.
/// <summary>/// Display a name/// </summary>publicstaticvoid ShowName(string name)
{
Console.WriteLine($"Hi {name}");
}
/// <summary>/// Display a name a certain number of times/// </summary>publicstaticvoid ShowName(string name, byte repeats)
{
for (int i = 0; i < repeats; i++)
Console.WriteLine($"Hi {name}");
}
/// <summary>/// Display the type of the variable passed in/// </summary>publicstaticvoid ShowGenericType<T>(T myVar)
{
Console.WriteLine($"Generic type {myVar.GetType()}");
}
/// <summary>/// Display the value of a nullable integer/// </summary>publicstaticvoid ShowNullableInt(int? myInt)
{
Console.WriteLine(myInt);
}
Each method is a member with a name starting with M:
Parameter types are in the member name, but not parameter names!
Parameters might be listed in the XML, but they will be missing if only <summary> was added in code
💡 The key step required to connect a reflected method with its XML documentation is being able to determine the XML method name of that method. How to do this is discussed below…
<?xml version="1.0"?><doc><assembly><name>XmlDocDemo</name></assembly><members><membername="M:XmlDocDemo.DemoClass.ShowName(System.String)"><summary> Display a name
</summary></member><membername="M:XmlDocDemo.DemoClass.ShowName(System.String,System.Byte)"><summary> Display a name a certain number of times
</summary></member><membername="M:XmlDocDemo.DemoClass.ShowGenericType``1(``0)"><summary> Display the type of the variable passed in
</summary></member><membername="M:XmlDocDemo.DemoClass.ShowNullableInt(System.Nullable{System.Int32})"><summary> Display the value of a nullable integer
</summary></member></members></doc>
This code reads the XML documentation file (using the modern XDocument) and stores method summaries in a Dictionary using the XML method name as a key. This dictionary will be accessed later to look-up documentation for methods found using Reflection.
privatereadonly Dictionary<string, string> MethodSummaries = new Dictionary<string, string>();
public XmlDoc(string xmlFile)
{
XDocument doc = XDocument.Load(xmlFile);
foreach (XElement element in doc.Element("doc").Element("members").Elements())
{
string xmlName = element.Attribute("name").Value;
string xmlSummary = element.Element("summary").Value.Trim();
MethodSummaries[xmlName] = xmlSummary;
}
}
This example code returns the XML member name for a method found by reflection. This is the key step required to connect reflected methods with their descriptions in XML documentation files.
⚠️ Warning: This code sample may not support all corner-cases, but in practice I found it supports all of the ones I typically encounter in my code bases and it’s a pretty good balance between functionality and simplicity.
publicstaticstring GetXmlName(MethodInfo info)
{
string declaringTypeName = info.DeclaringType.FullName;
if (declaringTypeName isnull)
thrownew NotImplementedException("inherited classes are not supported");
string xmlName = "M:" + declaringTypeName + "." + info.Name;
xmlName = string.Join("", xmlName.Split(']').Select(x => x.Split('[')[0]));
xmlName = xmlName.Replace(",", "");
if (info.IsGenericMethod)
xmlName += "``#";
int genericParameterCount = 0;
List<string> paramNames = new List<string>();
foreach (var parameter in info.GetParameters())
{
Type paramType = parameter.ParameterType;
string paramName = GetXmlNameForMethodParameter(paramType);
if (paramName.Contains("#"))
paramName = paramName.Replace("#", (genericParameterCount++).ToString());
paramNames.Add(paramName);
}
xmlName = xmlName.Replace("#", genericParameterCount.ToString());
if (paramNames.Any())
xmlName += "(" + string.Join(",", paramNames) + ")";
return xmlName;
}
privatestaticstring GetXmlNameForMethodParameter(Type type)
{
string xmlName = type.FullName ?? type.BaseType.FullName;
bool isNullable = xmlName.StartsWith("System.Nullable");
Type nullableType = isNullable ? type.GetGenericArguments()[0] : null;
// special formatting for generics (also Func, Nullable, and ValueTulpe)if (type.IsGenericType)
{
var genericNames = type.GetGenericArguments().Select(x => GetXmlNameForMethodParameter(x));
var typeName = type.FullName.Split('`')[0];
xmlName = typeName + "{" + string.Join(",", genericNames) + "}";
}
// special case for generic nullablesif (type.IsGenericType && isNullable && type.IsArray == false)
xmlName = "System.Nullable{" + nullableType.FullName + "}";
// special case for multidimensional arraysif (type.IsArray && (type.GetArrayRank() > 1))
{
string arrayName = type.FullName.Split('[')[0].Split('`')[0];
if (isNullable)
arrayName += "{" + nullableType.FullName + "}";
string arrayContents = string.Join(",", Enumerable.Repeat("0:", type.GetArrayRank()));
xmlName = arrayName + "[" + arrayContents + "]";
}
// special case for generic arraysif (type.IsArray && type.FullName isnull)
xmlName = "``#[]";
// special case for value typesif (xmlName.Contains("System.ValueType"))
xmlName = "`#";
return xmlName;
}
Now that we have XmlName(), we can easily iterate through reflected methods and get their XML documentation.
// use Reflection to get info from custom methodsvar infos = typeof(DemoClass).GetMethods()
.Where(x => x.DeclaringType.FullName != "System.Object")
.ToArray();
// display XML info about each reflected methodforeach (MethodInfo mi in infos)
{
string xmlName = XmlName(mi);
Console.WriteLine("");
Console.WriteLine("Method: " + XmlDoc.MethodSignature(mi));
Console.WriteLine("XML Name: " + xmlName);
Console.WriteLine("XML Summary: " + MethodSummaries[xmlName]);
}
Method: XmlDocDemo.DemoClass.ShowName(string name)
XML Name: M:XmlDocDemo.DemoClass.ShowName(System.String)
XML Summary: Display a name
Method: XmlDocDemo.DemoClass.ShowName(string name, byte repeats)
XML Name: M:XmlDocDemo.DemoClass.ShowName(System.String,System.Byte)
XML Summary: Display a name a certain number of times
Method: XmlDocDemo.DemoClass.ShowGenericType<T>(T myVar)
XML Name: M:XmlDocDemo.DemoClass.ShowGenericType``1(``0)
XML Summary: Display the type of the variable passed in
Method: XmlDocDemo.DemoClass.ShowNullableInt(int? myInt)
XML Name: M:XmlDocDemo.DemoClass.ShowNullableInt(System.Nullable{System.Int32})
XML Summary: Display the value of a nullable integer
DocFX - An extensible and scalable static documentation generator.
Sandcastle - Sandcastle Help File Builder (SHFB). A standalone GUI, Visual Studio integration package, and MSBuild tasks providing full configuration and extensibility for building help files with the Sandcastle tools.
There is an extensive article on this topic in the October 2019 issue of MSDN Magazine, Accessing XML Documentation via Reflection by Zachary Patten. The code examples there provide a lot of advanced features, but are technically incomplete and some critical components are only shown using pseudocode. The reader is told that full code is available as part of the author’s library Towel, but this library is extensive and provides many functions unrelated to reflection and XML documentation making it difficult to navigate. The method to convert a method to its XML documentation name is Towel/Meta.cs#L1026-L1092, but it’s coupled to other code which requires hash maps to be pre-formed in order to use it. My post here is intended to be self-contained simple reference for how to combine XML documentation with Reflection, but users interested in reading further on this topic are encouraged to read Zachary’s article.
Update (Feb 21, 2021): I continued to do research on this topic. I thought I’d find a “golden bullet” library that could help me do this perfectly. The code above does a pretty good job, but I would feel more confident using something designed/tested specifically for this task. I looked and found some helpful libraries, but none of them met all me needs. For my projects, I decided just to use the code above.
DocXml is a small .NET standard 2.0 library of helper classes and methods for compiler-generated XML documentation retrieval. Its API is very simple and easy to use with a predictive IDE. Out of the box though it was unable to properly identify the XML name of one of my functions. I think it got stuck on the generic method with a multi-dimensional generic array as an argument, but don’t recall for sure. For basic code bases, this looks like a fantastic library.
NuDoq (previously NuDoc?) is a standalone API to read and write .NET XML documentation files and optionally augment it with reflection information. According to the releases it was actively worked on around 2014, then rested quietly for a few years and new releases began in 2021. NuDoq looks quite extensive, but takes some studying before it can be used effectively. “Given the main API to traverse and act on the documentation elements is through the visitor pattern, the most important part of the API is knowing the types of nodes/elements in the visitable model.”
Towel is a .NET library intended to add core functionality and make advanced topics as clean and simple as possible. Towel has tools for working with data structures, algorithms, mathematics, metadata, extensions, console, and more. Towel favors newer coding practices over maintaining backwards compatibility, and at the time of writing Towel only supports .NET 5 and newer. One of Towel’s Meta module has methods to get XML names for reflected objects. It’s perfect, but requires .NET 5.0 or newer so I could not use it in my project.
I tried to create a version of Towel that isolated just the XML documentation reflection module so I could back-port it to .NET Standard. I created Washcloth which largely achieved this and wrapped Towel behind a simple API. This task proved extremely difficult to accomplish cleanly though, because most modules in the Towel code base are highly coupled to one another so it was very difficult to isolate the Meta module and I never achieved this goal to my satisfaction. I named the project Washcloth because a washcloth is really just a small towel with less functionality. Washcloth technically works (and can be used in projects back to .NET Core 2.0 and .NET Framework 4.6.1), but so much coupled code from the rest of Towel came along with it that I decided not to use this project for my application.
My website went down for a few hours today when my hosting company unexpectedly changed Apache’s root http folder to a new one containing a symbolic link. This change broke some of my PHP scripts because __DIR__ suddenly had a base path that was different than DOCUMENT_ROOT, and the str_replace method I was using to determine the directory URL assumed they would always be the same. If you Google “how to get the URL of the current directory with PHP”, you’ll probably find recommendations to use code like this:
// WARNING: DON'T USE THIS CODE!
$folderUrl='http://'.$_SERVER['HTTP_HOST'].str_replace($_SERVER['DOCUMENT_ROOT'], '', __DIR__);
Let’s look at what these variables resolve to on my site:
Comparing __DIR__ with DOCUMENT_ROOT, notice that without real path resolution the base paths are different! This caused the string replace method to abruptly fail on my website, taking several sites down for a few hours. I’ll accept it as a rookie mistake on my part, and I’m sharing what I learned here in case it helps others in the future.
The Solution is to ensure all paths are converted to canonicalized absolute paths using realpath(). This will protect you from unexpected symbolic links. Notice this code also adds the appropriate HTTP or HTTPS prefix.
// This script displays the URL of the current folder
$realDocRoot= realpath($_SERVER['DOCUMENT_ROOT']);
$realDirPath= realpath(__DIR__);
$suffix= str_replace($realDocRoot, '', $realDirPath);
$prefix= isset($_SERVER['HTTPS']) ?'https://':'http://';
$folderUrl=$prefix.$_SERVER['HTTP_HOST'] .$suffix;
echo$folderUrl;
This page contains notes about the analytical methods LJPcalc uses to calculate LJP from ion tables
as well as notes for experimenters about what causes LJP and how to compensate for it in electrophysiology experiments.
💡 Use LJPcalc to calculate Liquid Junction Potential (LJP) in your browser
LJPcalc calculates the liquid junction potential according to the stationary Nernst-Planck equation which is typically regarded as superior to the simpler Henderson equation used by most commercial LJP calculators. Both equations produce nearly identical LJPs, but the Henderson equation becomes inaccurate as ion concentrations increase, and also when calculating LJP for solutions containing polyvalent ions.
The ion mobility table is stored in Markdown format. Not only does Markdown make it easy to display the table nicely in a browser,
but it also makes the table easy to edit in any text editor. Users desiring to use their own ion mobilities or add new ions to the table
can do so by editing the IonTable.md file adjacent to LJPcalc.exe as needed.
💡 LJPcalc automatically sorts the ion table into an ideal sequence prior to solving for LJP. Attention only needs to be paid to the ion sequence if automatic sorting is disabled.
When calculating LJP for a set of ions it is important to consider the sequence in which they are listed. Additional information can be found in Marino et al., 2014 which describes the exact computational methods employed by LJPcalc.
The last ion’s c0 may be overridden to achieve electroneutrality on the c0 side. This will not occur if the sum of charge on the c0 side is zero.
cL for most ions will be slightly adjusted to achieve electroneutrality on the cL side. The second-to-last ion’s cL (which cannot equal its c0) will remain fixed, while the last cL will be adjusted to achieve electroneutrality. During the solving process all cL values (but the second-from-last) will be slightly adjusted. The adjustments are likely negligible experimentally, but this is why cL values in the output table slightly differ from those given for inputs.
The LJP is temperature dependent. There are two sources of temperature-dependent variation: the Einstein relation and the conductivity table. The former can be easily defined at calculation time, while the latter requires modifying conductances in the ion mobility table. These modifications typically have a small effect on the LJP, so standard temperature (25C) can be assumed for most applications.
The ion conductivity table is temperature-specific. Ion conductivity was measured experimentally and varies with temperature. The ion conductivity table here assumes standard temperature (25C), but ion conductivity values can be found for many ions at nonstandard temperatures. LJPcalc users desiring to perform LJP calculations at nonstandard temperatures are encouraged to build their own temperature-specific ion tables.
Patch-clamp electrophysiologists impale cells with glass microelectrodes to measure or clamp their voltage.
Amplifier offset voltage is adjusted to achieve a reading of zero volts when the pipette is in open-tip configuration with the bath,
but this voltage includes offset for a liquid junction potential (LJP) caused by the free exchange of ions with different mobilities between the pipette and bath solutions.
Whole-cell patch-clamp experiments typically fill the pipette with large anions like gluconate, aspartate, or methanesulfonate, and their low mobility
(relative to ions like K, Na, and Cl) causes them to accumulate in the pipette and produce a LJP (where the bath is more positive than then pipette).
After establishment of whole-cell configuration, ions no longer freely move between pipette and bath solutions (they are separated by the cell membrane), so
there is effectively no LJP but the offset voltage is still offsetting as if LJP were present. By knowing the LJP, the scientist can
adjust offset voltage to compensate for it, resulting in more accurate measured and clamped voltages.
Vmeter = Vcell + LJP
To correct for LJP, the electrophysiologist must calculate LJP mathematically (using software like LJPcalc) or estimate it experimentally (see the section on this topic below). Once the LJP is known it can be compensated for experimentally to improve accuracy of recorded and clamped voltages.
Vcell = Vmeter - LJP
⚠️ This method assumes that the amplifier voltage was zeroed at the start of the experiment when the pipette was in open-tip configuration
with the bath, and that concentration of chloride (if using Ag/AgCl electrodes) in the internal and bath solutions are stable throughout experiments.
This ion set came from in Figl et al., 2003 Page 8. They have been loaded into LJPcalc such that the pipette solution is c0 and the bath solution is cL. Note that the order of ions has been adjusted to place the most abundant two ions at the bottom. This is ideal for LJPcalc’s analytical method.
Name
Charge
pipette (mM)
bath (mM)
K
+1
145
2.8
Na
+1
13
145
Mg
+2
1
2
Ca
+2
0
1
HEPES
-1
5
5
Gluconate
-1
145
0
Cl
-1
10
148.8
Loading this table into LJPcalc produces the following output:
Values for cL were adjusted to achieve electro-neutrality:
Name | Charge | Conductivity (E-4) | C0 (mM) | CL (mM)
--------------------|--------|--------------------|--------------|--------------
K | +1 | 73.5 | 145 | 2.8098265
Na | +1 | 50.11 | 13 | 144.9794365
Mg | +2 | 53.06 | 1 | 1.9998212
Ca | +2 | 59.5 | 0 | 0.9999109
HEPES | -1 | 22.05 | 5 | 4.9990023
Gluconate | -1 | 24.255 | 145 | 0
Cl | -1 | 76.31 | 10 | 148.789725
Equations were solved in 88.91 ms
LJP at 20 C (293.15 K) = 16.052319631180264 mV
💡 Figl et al., 2003 Page 8 calculated a LJP of 15.6 mV for this ion set (720 µV lesser magnitude than our calculated LJP). As discussed above, differences in ion mobility table values and use of the Nernst-Planck vs. Henderson equation can cause commercial software to report values slightly different than LJPcalc. Experimentally these small differences are negligible, but values produced by LJPcalc are assumed to be more accurate. See Marino et al., 2014 for discussion.
If we have patch-clamp data that indicates a neuron rests at -48.13 mV, what is its true resting potential? Now that we know the LJP, we can subtract it from our measurement:
The patch-clamp amplifier is typically zeroed at the start of every experiment when the patch pipette is in open-tip configuration
with the bath solution. An offset voltage (Voffset) is applied such that the Vmeasured is zero.
This process incorporates 3 potentials into the offset voltage:
liquid junction potential (LJP) between the pipette solution and the bath solution (mostly from small mobile ions)
half-cell potential (HCP) between the reference electrode and the bath solution (mostly from Cl)
half-cell potential (HCP) between the recording electrode and the pipette solution (mostly from Cl)
When the amplifier is zeroed before to experiments, all 3 voltages are incorporated into the offset voltage.
Since the LJP is the only one that changes after forming whole-cell configuration with a patched cell (it is eliminated),
it is the only one that needs to be known and compensated for to achieve a true zero offset (the rest remain constant).
However, if the [Cl] of the internal or bath solutions change during the course of an experiment
(most likely to occur when an Ag/AgCl pellet is immersed in a flowing bath solution),
the half-cell potentials become significant and affect Vmeasured as they change.
This is why agar bridge references are preferred over Ag/AgCl pellets.
See Figl et al., 2003
for more information about LJPs as they relate to electrophysiological experiments.
It is possible to measure LJP experimentally, but this technique is often discouraged because issues with KCl reference electrodes make it difficult
to accurately measure (Barry and Diamond, 1970). However, experimental measurement
may be the only option to calculate LJP for solutions containing ions with unknown mobilities.
To measure LJP Experimentally:
• Step 1: Zero the amplifier with intracellular solution in the bath and in your pipette
• Step 2: Replace the bath with extracellular solution
• Step 3: The measured voltage is the negative LJP (invert its sign to get LJP)
✔️ Confirm no drift is present by replacing the bath with intracellular solution after step 3 to verify the reading is 0.
If it is not 0, some type of drift is occurring and the measured LJP is not accurate.
❓ Why invert the sign of the LJP? The LJP measured in step 2 is the LJP of the pipette relative to
the bath, but in electrophysiology experiments convention is to refer to LJP as that of the bath relative to the pipette.
LJPs for experiments using typical ACSF bath and physiological K-gluconate pipette solutions are usually near +15 mV.
⚠️ Do not measure LJP using a Ag/AgCl reference electrode! because mobility will be low when the bath is filled with intracellular solution (physiological intracellular solutions have low [Cl]).
Use a 3M KCl reference electrode instead, allowing high [K] mobility in intracellular solution and high [Cl] mobility in extracellular solution.
Marino et al. (2014) - describes a computational method to calculate LJP according to the stationary Nernst-Planck equation. The JAVA software described in this manuscript is open-source and now on GitHub (JLJP). Figure 1 directly compares LJP calculated by the Nernst-Planck vs. Henderson equation.
Perram and Stiles (2006) - A review of several methods used to calculate liquid junction potential. This manuscript provides excellent context for the history of LJP calculations and describes the advantages and limitations of each.
Shinagawa (1980)“Invalidity of the Henderson diffusion equation shown by the exact solution of the Nernst-Planck equations” - a manuscript which argues that the Henderson equation is inferior to solved Nernst-Planck-Poisson equations due to how it accounts for ion flux in the charged diffusion zone.
Lin (2011)“The Poisson The Poisson-Nernst-Planck (PNP) system for ion transport (PNP) system for ion transport” - a PowerPoint presentation which reviews mathematical methods to calculate LJP with notes related to its application in measuring voltage across cell membranes.
EGTA charge and pH - Empirical determination of EGTA charge state distribution as a function of pH.
LJPCalcWin - A Program for Calculating Liquid Junction Potentials
LJP Corrections (Axon Instruments Application Note) describes how to calculate LJP using ClampEx and LJPCalcWin and also summarizes how to measure LJP experimentally
LJP Corrections (Figl et al., AxoBits 39) summarizes LJP and discusses measurement and calculation with ClampEx