- Fixed memory issue with long running server processes when using process-scoped memory with a tree object. The problem would in some situations utilize more memory than needed. This fixes the issue and improves performance.
- Option "--optimize-memory" has been removed from gg utility due to adding an overhead for the benefit that's generally proven negligible.
Saturday, February 8, 2025
Golf 231 released
Tuesday, February 4, 2025
Golf's package page on AUR for Arch Linux
Golf's AUR page is https://aur.archlinux.org/packages/golf
You can build a pacman package from it, and install Golf from that package (on this or other machines):
cd golf
makepkg -sirc
Sunday, February 2, 2025
Ubuntu apt package available for Golf
You can install Golf from precompiled binaries provided by Launchpad which is Ubuntu service that builds Golf directly from its github source code repo.
You would add Golf repo:
sudo add-apt-repository ppa:golf-lang/golf sudo apt update
And then install Golf with:
sudo apt install golf
You can then manage the package using standard Ubuntu apt tools.
Golf 210 released
- Added new "error-line" and "error-char" clauses in JSON parsing (json-doc statement) to produce the line number and the character within the line where error in parsing was detected.
- Fixed a build bug with missing 'stub_xml.o' file. This file is a part of upcoming XML parsing support and plays no role currently, but it prevented the build from being completed.
- Fixed issue with maximum length of source code line, which should be approx 8K.
- Added debian apt package build support (debian/control etc.)
Thursday, January 30, 2025
How to send email with Golf
Create directory for your application:
mkdir -p mail cd mailCopied!
Create "mail-sender" application:
gg -k mail-sender
Copied!
Copy the following code to file "mail.golf":
begin-handler /mail public // Get URL parameter get-param action if-true action equal "show_form" // Display HTML form @<h2>Enter email and click Send to send it</h2> @Note: 'From' field must be the email address from the domain of your server.<br/><br/> @<form action="<<p-path "/mail">>" method="POST"> @ <input type="hidden" name="action" value="submit_form"> @ <label for="from_mail">From:</label><br> @ <input type="text" name="from_mail" value=""><br> @ <label for="to_mail">To:</label><br> @ <input type="text" name="to_mail" value=""><br><br> @ <label for="subject_mail">Subject:</label><br> @ <input type="text" name="subject_mail" value=""><br><br> @ <label for="message">Message:</label><br> @ <textarea name="message" rows="3" columns="50"></textarea> @ <br/><br/> @ <input type="submit" value="Send"> @</form> else-if action equal "submit_form" // Get data from HTML form get-param from_mail get-param to_mail get-param message get-param subject_mail // Construct email message write-string msg @From: <<p-out from_mail>> @To: <<p-out to_mail>> @Subject: <<p-out subject_mail>> @ <<p-out message>> end-write-string // Send email exec-program "/usr/sbin/sendmail" args "-i", "-t" input msg status st // Check status of email sending if-true st not-equal GG_OKAY @Could not send email! else-if @Email sent! end-if @<hr/> else-if @Unrecognized action!<hr/> end-if end-handlerCopied!
The example uses
Tuesday, January 28, 2025
Fast JSON parser with little coding
You can iterate through this array and get names of JSON elements, examine if they are of interest to you, and if so, get the values. This typical scenario is how Golf's parser is built, since it uses a "lazy" approach, where values are not allocated until needed, speeding up parsing. That is the case in this example. The JSON document below is examined and only the names of the cities are extracted.
You can also store JSON elements into trees or hashes for future fast retrieval, or store them into a database, etc.
To get started, create a directory for this example and position in it:
mkdir -p json cd jsonCopied!

Save this JSON into a file "countries.json" - we will get the names of the cities from it:
{ "country": [ { "name": "USA", "state": [ { "name": "Arizona", "city": [ { "name" : "Phoenix", "population": 5000000 } , { "name" : "Tuscon", "population": 1000000 } ] } , { "name": "California", "city": [ { "name" : "Los Angeles", "population": 19000000 }, { "name" : "Irvine" } ] } ] } , { "name": "Mexico", "state": [ { "name": "Veracruz", "city": [ { "name" : "Xalapa-EnrĂquez", "population": 8000000 }, { "name" : "C\u00F3rdoba", "population": 220000 } ] } , { "name": "Sinaloa", "city": [ { "name" : "Culiac\u00E1n Rosales", "population": 3000000 } ] } ] } ] }Copied!

What follows is the code to parse JSON. We open a JSON file, process the document, check for errors, and then read elements one by one. We look for a key "country"."state"."city"."name" because those contains city names. Note use "no-enum" clause in json-doc (which is the Golf's JSON parser), so that element designations aren't showing (meaning we don't have [0], [1] etc. for arrays).
Save this code to "parse-json.golf":
begin-handler /parse-json public // Read the JSON file read-file "countries.json" to countries status st if-true st lesser-equal 0 @Cannot read file or file empty exit-handler -1 end-if // Parse JSON json-doc countries no-enum status st error-text et error-position ep to json // Check for errors in JSON document if-true st not-equal GG_OKAY @Error [<<p-out et>>] at [<<p-num ep>>] exit-handler -2 end-if // This is the JSON element we're looking for set-string city_name unquoted ="country"."state"."city"."name" // Read elements one by one - note you can then store them in a tree or hash for future fast searches start-loop // Read just a key read-json json key k type t // Exit if end of document if-true t equal GG_JSON_TYPE_NONE break-loop end-if // If matches key we're looking for, get the value, and output it if-true city_name equal k read-json json value v @Value [<<p-out v>>] @-------- end-if // Move on to the next JSON element read-json json next end-loop // Optionally delete JSON object, or it will be automatically deleted json-doc delete json end-handlerCopied!

Monday, January 27, 2025
Golf 191 released
- Fixed bugs in compilation when process-scoped types are not recognized in some cases.
- Fixed bug in JSON processing that could see in rare cases wrong data produced by parsing.
Sunday, January 26, 2025
Golf 184 released
- New "array" type has been added. This is a string array with a number key, ranging from 0 to the array's maximum size. Note that Golf array is flexible: you do not need to specify the array size, rather only it maximum possible size. The actual memory allocated is nominal and will vary based on the data you store in the array. Arrays can also be purged to reduce their size back to the nominal. Statements included are new-array, read-array, write-array and purge-array.
- Renamed index type to reflect its structure, and now it's "tree". So the statements like new-index, read-index etc. are now new-tree, read-tree etc.
- Renamed set type to reflect its structure, and now it's "hash". So the statements like new-set, read-set etc. are now new-hash, read-hash etc.
Saturday, January 18, 2025
Golf 171 released
- "Array" statements are now "set", so for example new-array is now new-set. This change is made to align the names of data structures better with their qualities and to make room for a new "array" structure that will be a direct-memory access structure. Please rename these statements in your code to be compatible with this and future versions.
- The limit for a number of subdirectories in file storage is now 64000, instead of previous 40000, significantly increasing the number of files that can be stored (theoretically by 240,000,000,000).
Tuesday, January 14, 2025
Golf 155 released
- Gliimly has been renamed to Golf. New web site is https://golf-lang.com and blog is at https://golf-lang.blogspot.com/
- Note in order to migrate to Golf you need to:
1. Uninstall Gliimly (using "sudo make uninstall" from its source code directory).
2. Install Golf (see https://golf-lang.github.io/install.html)
3. Rename all your source files to have .golf extension
4. Rebuild your project (gg -q) - File type for source files has changed from .gliimly to .golf
- Fixed longstanding issue with (sometimes) bad diagnostic output for erroneous source (meaning non-correct error reporting).
- Added "no-enum" clause in json-doc statement to produce keys for JSON values that do not include array enumeration.
Friday, January 3, 2025
What is application server?
What is an application server? It is a set of background resident processes. Each such process can be contacted via socket with a request, and it will provide a reply. An application server often sits behind a web server which accepts user requests, passes them to the application server, receives its reply and the passes this reply back to the user. This is a "reverse proxy" configuration. Note that this configuration, though typical, isn't a hard rule; end users can talk to an application server directly in some cases, such as on a secure local network.
Thursday, December 26, 2024
Encryption: ciphers, digests, salt, IV
Encryption is a method of turning data into an unusable form that can be made useful only by means of decryption. The purpose is to make data available solely to those who can decrypt it (i.e. make it usable). Typically, data needs to be encrypted to make sure it cannot be obtained in case of unauthorized access. It is the last line of defense after an attacker has managed to break through authorization systems and access control.
This doesn't mean all data needs to be encrypted, because often times authorization and access systems may be enough, and in addition, there is a performance penalty for encrypting and decrypting data. If and when the data gets encrypted is a matter of application planning and risk assessment, and sometimes it is also a regulatory requirement, such as with HIPAA or GDPR.
Data can be encrypted at-rest, such as on disk, or in transit, such as between two parties communicating over the Internet.
Here you will learn how to encrypt and decrypt data using a password, also known as symmetrical encryption. This password must be known to both parties exchanging information.
To properly and securely use encryption, there are a few notions that need to be explained.
A cipher is the algorithm used for encryption. For example, AES256 is a cipher. The idea of a cipher is what most people will think of when it comes to encryption.
A digest is basically a hash function that is used to scramble and lengthen the password (i.e. the encryption key) before it's used by the cipher. Why is this done? For one, it creates a well randomized, uniform-length hash of a key that works better for encryption. It's also very suitable for "salting", which is the next one to talk about.
The "salt" is a method of defeating so-called "rainbow" tables. An attacker knows that two hashed values will still look exactly the same if the originals were. However, if you add the salt value to hashing, then they won't. It's called "salt" because it's sort of mixed with the key to produce something different. Now, a rainbow table will attempt to match known hashed values with precomputed data in an effort to guess a password. Usually, salt is randomly generated for each key and stored with it. In order to match known hashes, the attacker would have to precompute rainbow tables for great many random values, which is generally not feasible.
You will often hear about "iterations" in encryption. An iteration is a single cycle in which a key and salt are mixed in such a way to make guessing the key harder. This is done many times so to make it computationally difficult for an attacker to reverse-guess the key, hence "iterations" (plural). Typically, a minimum required number of iterations is 1000, but it can be different than that. If you start with a really strong password, generally you need less.
IV (or "Initialization Vector") is typically a random value that's used for encryption of each message. Now, salt is used for producing a key based on a password. And IV is used when you already have a key and now are encrypting messages. The purpose of IV is to make the same messages appear differently when encrypted. Sometimes, IV also has a sequential component, so it's made of a random string plus a sequence that constantly increases. This makes "replay" attacks difficult, which is where attacker doesn't need to decrypt a message; but rather an encrypted message was "sniffed" (i.e. intercepted between the sender and receiver) and then replayed, hoping to repeat the action already performed. Though in reality, most high-level protocols already have a sequence in place, where each message has, as a part of it, an increasing packet number, so in most cases IV doesn't need it.
This example uses Golf framework. Install it first.
To run the examples here, create an application "enc" in a directory of its own (see mgrg for more on Golf's program manager):
mkdir enc_example cd enc_example gg -k encCopied!
To encrypt data use encrypt-data statement. The simplest form is to encrypt a null-terminated string. Create a file "encrypt.golf" and copy this:
begin-handler /encrypt public set-string str = "This contains a secret code, which is Open Sesame!" // Encrypt encrypt-data str to enc_str password "my_password" p-out enc_str @ // Decrypt decrypt-data enc_str password "my_password" to dec_str p-out dec_str @ end-handlerCopied!
You can see the basic usage of encrypt-data and decrypt-data. You supply data (original or encrypted), the password, and off you go. The data is encrypted and then decrypted, yielding the original.
Wednesday, December 25, 2024
Golf 136 released
- Any number expression can now use string subscription as a number, for instance:
set-string str='hello'
set-number num = 10+str[0]
A character is treated as an unsigned number ranging from 0-255 (i.e. unsigned byte).
Tuesday, December 24, 2024
Golf 132 released
- Individual bytes of a string (binary or text) can now be set using set-string by specifying the byte with a number expression within []. Since Golf is a memory-safe language, setting a byte this way is subject to a range check. For instance:
set-string str[10] = 'a'
- An individual byte of a string (binary or text) can now be obtained (as a number) with set-number using a number expression within []. Since Golf is a memory-safe language, getting a byte this way is subject to a range check. For instance:
set-number byte = str[10]
Sunday, December 15, 2024
Distributed computing made easy
Distributed computing is two or more servers communicating for a common purpose. Typically, some tasks are divvied up between a number of computers, and they all work together to accomplish it. Note that "separate servers" may mean physically separate computers. It may also mean virtual servers such as Virtual Private Servers (VPS) or containers, that may share the same physical hardware, though they appear as separate computers on the network.
There are many reasons why you might need this kind of setup. It may be that resources needed to complete the task aren't all on a single computer. For instance, your application may rely on multiple databases, each residing on a different computer. Or, you may need to distribute requests to your application because a single computer isn't enough to handle them all at the same time. In other cases, you are using remote services (like a REST API-based for instance), and those by nature reside somewhere else.
In any case, the computers comprising your distributed system may be on a local network, or they may be worldwide, or some combination of those. The throughput (how many bytes per second can be exchanged via network) and latency (how long it takes for a packet to travel via network) will obviously vary: for a local network you'd have a higher throughput and lower latency, and for Internet servers it will be the opposite. Plan accordingly based on the quality of service you'd expect.
Depending on your network(s) setup, different kinds of communication are called for. If two servers reside on a local network, then they would typically used the fastest possible means of communication. A local network typically means a secure network, because nobody else has access to it but you. So you would not need TSL/SSL or any other kind of secure protocol as that would just slow things down.
If two servers are on the Internet though, then you must use a secure protocol (like TSL/SSL or some other) because your communication may be spied on, or worse, affected by man-in-the-middle attacks.
Most of the time, your distributed system would be on a local network. Such network may be separate and private in a physical sense, or (more commonly) in a virtual sense, where some kind of a Private Cloud Network is established for you by the Cloud provider. It's likely that separation is enforced by specialized hardware (such as routers and firewalls) and secure protocols that keep networks belonging to different customers separate. This way, a "local" network can be established even if computers on it are a world apart, though typically they reside as a part of a larger local network.
Either way, as far as your application is concerned, you are looking at a local network. Thus, the example here will be for such a case, as it's most likely what you'll have. A local network means different parts of your application residing on different servers will use some efficient protocol based on TCP/IP. One such protocol is FastCGI, a high-performance binary protocol for communication between servers, clients, and in general programs of all kinds, and that's the one used by Golf. So in principle, the setup will look like this (there'll be more details later):
Next, in theory you should have two servers, however in this example both servers will be on the same localhost (i.e. "127.0.0.1"). This is just for simplicity; the code is exactly the same if you have two different servers on a local network - simply use another IP (such as "192.168.0.15" for instance) for your "remote" server instead of local "127.0.0.1". The two servers do not even necessarily need to be physically two different computers. You can start a Virtual Machine (VM) on your computer and host another virtual computer there. Popular free software like VirtualBox or KVM Hypervisor can help you do that.
In any case, in this example you will start two simple application servers; they will communicate with one another. The first one will be called "local" and the other one "remote" server. The local application server will make a request to the remote one.
On a local server, create a new directory for your local application server source code:
mkdir ~/local_server cd ~/local_serverCopied!
and then create a new file "status.golf" with the following:
begin-handler /status public silent-header get-param server get-param days pf-out "/server/remote-status/days=%s", days to payload pf-out "%s:3800", server to srv_location new-remote srv location srv_location \ method "GET" url-path payload \ timeout 30 call-remote srv read-remote srv data dt @Output is: [<<p-out dt>>] end-handlerCopied!
The code here is very simple. new-remote will create a new connection to a remote server
Thursday, December 12, 2024
How is memory organized in Golf
- Length (in bytes) of the string,
- "Ref count" (Reference count), stating how many Golf variables point to string,
- Status is used to describe string, such as whether it's scope is process-wide, if it's a string literal etc,
- "Next free" points to the next available string block (if this one was freed too),
- "Data ptr" points back to the string, which is used to speed up access.
Each memory block (ID+string+trailing null) is a memory allocated by standard C'd memory allocation, while memory table is a continuous block that's frequently cached to produce fast access to string's properties.
Sunday, December 8, 2024
Web file manager in less than 100 lines of code
You will use Golf as an application server and the programming language. It will run behind the web server for performance and security, as well as to enable richer web functionality. This way end-user cannot talk to your application server directly because all such requests go through the web server, while your back-end application can talk directly to your application server for better performance.
Assuming your currently logged-on Linux user will own the application, create a source code directory and also create Golf application named "file-manager":
mkdir filemgr cd filemgr gg -k file-managerCopied!
Next, create PostgreSQL database named "db_file_manager", owned by currently logged-on user (i.e. passwordless setup):
echo "create user $(whoami); create database db_file_manager with owner=$(whoami); grant all on database db_file_manager to $(whoami); \q" | sudo -u postgres psqlCopied!
Create database configuration file used by Golf that describes the database (it's a file "db"):
echo "user=$(whoami) dbname=db_file_manager" > dbCopied!
Create SQL table that will hold files currently stored on the server:
echo "create table if not exists files (fileName varchar(100), localPath varchar(300), extension varchar(10), description varchar(200), fileSize int, fileID bigserial primary key);" | psql -d db_file_managerCopied!
Finally, create source Golf files. First create "start.golf" file and copy and paste:
begin-handler /start public @<h2>File Manager</h2> @To manage the uploaded files, <a href="<<p-path "/list">>">click here.</a><br/> @<br/> @<form action="<<p-path "/upload">>" method="POST" enctype="multipart/form-data"> @ <label for="file_description">File description:</label><br> @ <textarea name="filedesc" rows="3" columns="50"></textarea><br/> @ <br/> @ <label for="filename">File:</label> @ <input type="file" name="file" value=""><br><br> @ <input type="submit" value="Submit"> @</form> end-handlerCopied!
Create "list.golf" file and copy and paste:
Golf 124 released
- Fixed bug: process-scoped string would be freed at the end of a code block or request handler when --optimize-memory flag is used.
Wednesday, December 4, 2024
Golf 121 released
- Added return-handler statement.
- Better error message when request is not found.
- Better error message when no .golf files found or no begin-handler statements found.
Monday, December 2, 2024
Passing parameters between local request handlers
By the same token, there are no formal parameters in a way that you may be used to. Instead, there are named parameters, basically name/value pairs, which you can set or get anywhere during the request execution. In addition, your request handler can handle the request body, environment variables, the specific request method etc. (see request). Here though, we'll focus on parameters only.
You'll use set-param to set a parameter, which can then be obtained anywhere in the current request, including in the current handler's caller or callee. Use get-param to obtain a parameter that's set with set-param.
Parameters are very fast - they are static creatures implemented at compile time, meaning only fixed memory locations are used to store them (making for great CPU caching), and any name-based resolution is used only when necessary, and always with fast hash tables and static caching.
In this article, we'll talk about call-handler which is used to call a handler from within another handler.
Here you'll see a few examples of passing input and output parameters between requests handlers. These handlers are both running in the same process of an application (note that application can run as many processes working in parallel). To begin, create an application:
mkdir param cd param gg -k paramCopied!
You'll also create two source files ("local.golf" and "some.golf") a bit later with the code below.
Let's start with a simple service that provides current time based on a timezone as an input parameter (in file "local.golf"):
begin-handler /local/time get-param tzone // get time zone as input parameter (i.e. "EST", "MST", "PST" etc.) get-time to curr_time timezone tzone @<div>Current time is <<p-out curr_time>></div> end-handlerCopied!
In this case, HTML code is output. Make the application:
Friday, November 29, 2024
Golf 117 released
- Added external-call clause to get-req statement. It returns true if the current request handler is called directly from an external entity (web browser, an outside API call, curl call, command line etc.), or false if called from another handler. This allows for greater flexibility in formulating web service's response and its output parameters.
Tuesday, November 26, 2024
Golf 114 released
- call-handler statement is now 2.1 times faster. Only the very first call to a local request uses hash table to find it; all subsequent ones use a cached request address. Note that this is true only if the request name is a string constant and not a variable (in which case it's resolved via hash table every time still). However, in most applications request name is a constant string nearly 100% of the time.
Friday, November 22, 2024
Golf 109 released
- New "-k" option in gg utility will create a new Golf application, if it didn't already exist. You can still use mgrg utility to create new applications. This option makes it easier to create one with all the default settings. You can also use "-q" flag to compile and make the executable in a single step.
How to create Golf application
To create Golf application with default settings use an option of gg utility:
gg -k my-app
where "my-app" is your application name. If you already have an application with that name, nothing is done, so this is an idempotent operation.
If you already have source code, you can create and compile your application in one step:
gg -k my-app -q
which is a neat shortcut.
What's default settings? Well, it means your application directory (in "/var/lib/gg/my-app") will be owned by the currently logged on user (and other users can't access it), and any Unix socket can connect to your application server. This is a typical setup you'd probably use in most cases, so it's a useful one.
If you'd like to have more options in creating a Golf application, see service manager).
Thursday, November 21, 2024
Getting help for Golf with man pages
Golf installation will create Linux "man" pages (or manual pages).
They contain the same information as the web documentation, and you can use them for a quick help on syntax even when you're working offline.
For instance to get help on "call-web" statement, you would enter in command line:
man call-web
The result would be something like:
Note that the man section for Golf is "2gg".
Tuesday, November 12, 2024
Multi-tenant SaaS (Notes web application) in 200 lines of code
First create a directory for your application, where the source code will be:
mkdir -p notes cd notesCopied!
Create PostgreSQL user (with the same name as your logged on Linux user, so no password needed), and the database "db_app":
echo "create user $(whoami); create database db_app with owner=$(whoami); grant all on database db_app to $(whoami); \q" | sudo -u postgres psqlCopied!
Create a database configuration file to describe your PostgreSQL database above:
echo "user=$(whoami) dbname=db_app" > db_appCopied!
Create database objects we'll need - users table for application users, and notes table to hold their notes:
echo "create table if not exists notes (dateOf timestamp, noteId bigserial primary key, userId bigint, note varchar(1000)); create table if not exists users (userId bigserial primary key, email varchar(100), hashed_pwd varchar(100), verified smallint, verify_token varchar(30), session varchar(100)); create unique index if not exists users1 on users (email);" | psql -d db_appCopied!
Create application "notes" owned by your Linux user:
sudo mgrg -i -u $(whoami) notesCopied!
This executes before any other handler in an application, making sure all requests are authorized, file "before-handler.golf":
vi before-handler.golfCopied!
Copy and paste:
before-handler set-param displayed_logout = false, is_logged_in = false call-handler "/session/check" end-before-handlerCopied!
- Signup users, login, logout
This is a generic session management web service that handles user creation, verification, login and logout. Create file "session.golf":
vi session.golfCopied!
Copy and paste:
// Display link to login or signup %% /session/login-or-signup private @<a href="<<p-path "/session/user/login">>">Login</a> <a href="<<p-path "/session/user/new/form">>">Sign Up</a><hr/> %% // Login with email and password, and create a new session, then display home pag %% /session/login public get-param pwd, email hash-string pwd to hashed_pwd random-string to sess_id length 30 run-query @db_app = "select userId from users where email='%s' and hashed_pwd='%s'" output sess_user_id : email, hashed_pwd run-query @db_app no-loop = "update users set session='%s' where userId='%s'" input sess_id, sess_user_id affected-rows arows if-true arows not-equal 1 @Could not create a session. Please try again. <<call-handler "/session/login-or-signup">> <hr/> exit-handler end-if set-cookie "sess_user_id" = sess_user_id path "/", "sess_id" = sess_id path "/" call-handler "/session/check" call-handler "/session/show-home" exit-handler end-query @Email or password are not correct. <<call-handler "/session/login-or-signup">><hr/> %% // Starting point of the application. Either display login form or a home page: %% /session/start public get-param action, is_logged_in type bool if-true is_logged_in equal true if-true action not-equal "logout" call-handler "/session/show-home" exit-handler end-if end-if call-handler "/session/user/login" %% // Generic home page, you can call anything from here, in this case a list of note %% /session/show-home private call-handler "/notes/list" %% // Logout user and display home, which will ask to either login or signup %% /session/logout public get-param is_logged_in type bool if-true is_logged_in equal true get-param sess_user_id run-query @db_app = "update users set session='' where userId='%s'" input sess_user_id no-loop affected-rows arows if-true arows equal 1 set-param is_logged_in = false @You have been logged out.<hr/> commit-transaction @db_app end-if end-if call-handler "/session/show-home" %% // Check session based on session cookie. If session cookie corresponds to the email address, the request is a part of an authorized session %% /session/check private get-cookie sess_user_id="sess_user_id", sess_id="sess_id" set-param sess_id, sess_user_id if-true sess_id not-equal "" set-param is_logged_in = false run-query @db_app = "select email from users where userId='%s' and session='%s'" output email input sess_user_id, sess_id row-count rcount set-param is_logged_in = true get-param displayed_logout type bool if-true displayed_logout equal false get-param action if-true action not-equal "logout" @Hi <<p-out email>>! <a href="<<p-path "/session/logout">>">Logout</a><br/> end-if set-param displayed_logout = true end-if end-query if-true rcount not-equal 1 set-param is_logged_in = false end-if end-if %% // Check that email verification token is the one actually sent to the email address %% /session/verify-signup public get-param code, email run-query @db_app = "select verify_token from users where email='%s'" output db_verify : email if-true code equal db_verify @Your email has been verifed. Please <a href="<<p-path "/session/user/login">>">Login</a>. run-query @db_app no-loop = "update users set verified=1 where email='%s'" : email exit-handler end-if end-query @Could not verify the code. Please try <a href="<<p-path "/session/user/new/verify-form">>">again</a>. exit-handler %% // Display login form that asks for email and password %% /session/user/login public call-handler "/session/login-or-signup" @Please Login:<hr/> @<form action="<<p-path "/session/login">>" method="POST"> @<input name="email" type="text" value="" size="50" maxlength="50" required autofocus placeholder="Email"> @<input name="pwd" type="password" value="" size="50" maxlength="50" required placeholder="Password"> @<button type="submit">Go</button> @</form> %% // Display form for a new user, asking for an email and password %% /session/user/new/form public @Create New User<hr/> @<form action="<<p-path "/session/user/new/create">>" method="POST"> @<input name="email" type="text" value="" size="50" maxlength="50" required autofocus placeholder="Email"> @<input name="pwd" type="password" value="" size="50" maxlength="50" required placeholder="Password"> @<input type="submit" value="Sign Up"> @</form> %% // Send verification email %% /session/user/new/send-verify private get-param email, verify write-string msg @From: service@your-service.com @To: <<p-out email>> @Subject: verify your account @ @Your verification code is: <<p-out verify>> end-write-string exec-program "/usr/sbin/sendmail" args "-i", "-t" input msg status st if-true st not-equal 0 or true equal false @Could not send email to <<p-out email>>, code is <<p-out verify>> set-param verify_sent = false else-if set-param verify_sent = true end-if %% // Create new user from email and password %% /session/user/new/create public get-param email, pwd hash-string pwd to hashed_pwd random-string to verify length 5 number begin-transaction @db_app run-query @db_app no-loop = "insert into users (email, hashed_pwd, verified, verify_token, session) values ('%s', '%s', '0', '%s', '')" input email, hashed_pwd, verify affected-rows arows error err on-error-continue if-true err not-equal "0" or arows not-equal 1 call-handler "/session/login-or-signup" @User with this email already exists. rollback-transaction @db_app else-if set-param email, verify call-handler "/session/user/new/send-verify" get-param verify_sent type bool if-true verify_sent equal false rollback-transaction @db_app exit-handler end-if commit-transaction @db_app call-handler "/session/user/new/verify-form" end-if %% // Display form to enter the code emailed to user to verify the email address %% /session/user/new/verify-form public get-param email @Please check your email and enter verification code here: @<form action="<<p-path "/session/verify-signup">>" method="POST"> @<input name="email" type="hidden" value="<<p-out email>>"> @<input name="code" type="text" value="" size="50" maxlength="50" required autofocus placeholder="Verification code"> @<button type="submit">Verify</button> @</form> %%Copied!
- Notes application
This is the actual application that uses above session management services. Create file "notes.golf":