Let's Go: Ch 10-12

Adding HTTPS

On production¹ , you would use a third-party to create TLS certificates. But for development, a self-signed TLS certificate is more than enough.

The go standard library also includes a handy package called crypto/tls for us to generate our own certificates.

Cookies

Cookies should only be sent to the user on a secure connection. Remember to always make sure to only send cookies on a HTTPS connection using your session manager.

Ran Into a Small Problem With Go

My system wasn’t able to find the standard library and run:

go run /usr/local/go/src/crypto/tls/generate_cert.go --rsa-bits=2048 --host=localhost

I ended having to re-install go and adding /usr/local/go to my $PATH.

Configuring HTTPS Settings

The book mentions elliptic curves but doesn’t really go into what it is. Wikipedia gives a nice and simple description of it.

Something to think about: timeouts

Connection timeouts are important for servers. By default, Go will keep-alive connections for a few minutes, but we can reduce this time in our server settings.

  srv := &http.Server{
  // ...other settings
    TLSConfig: tlsConfig,
    IdleTimeout: time.Minute,
    ReadTimeout: 5 * time.Second,
    WriteTimeout: 10 * time.Second,
  }

ReadTimeout is important for mitigating risk from slow-attack clients. WriteTimeout is generally used to prevent data that the handler returns from taking too long to write.

User Authentication

Regex for Email

If you need to validate for input for email, use the one recommended by W3C and Web Hypertext Application Technology Working Group. The regex can be found here.

/^[a-zA-Z0-9.!#$%&'*+\/=?^_`{|}~-]+@[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?(?:\.[a-zA-Z0-9](?:[a-zA-Z0-9-]{0,61}[a-zA-Z0-9])?)*$/

Adding a New User With an Existing Email, Something to Look Out For

For this project, when a user signs up (with an email that already exists), the backend will try to insert a new user into the database and then will receive an error. This means that we would have to check for this error before sending data back to the user. This isn’t really a great method for checking if the user already exists. What if the database changes its error codes?

One solution, would be to check if the exists before inserting new data. This is the way I’ve always done it. But when two users try to sign up with the same email at the same time, there is a race condition. The validation would pass for both but only one will be inserted into the database.

It’s important as a backend developer to think critically about your logic and write code that avoids race conditions.

When a User Tries to Log In with the Wrong Credentials…

Never ever return a password was incorrect or email was incorrect. It is way too specific. Authentication errors sent back to the user should always be vague. You don’t want your account to be so easily hacked through an error message.

Request Context

Request context is a value that is passed down every time there is a request. The context allows us to access data from any function that has the argument http.Request.

Resources

• OWASP Cheatsheets - provides good security practices

Relevant Posts

• Let’s Go Ch 1-4
• Let’s Go Ch 5-9
• Let’s Go Ch 13-14