

Building a Web Server in Go: Handling User Input - lettergram
http://austingwalters.com/building-a-web-server-in-go-user-input/

======
carbocation

        usr.Password = codify.SHA(pass)
    

In modern code examples, please don't do things like just SHA plaintext
passwords. Someone might copy it verbatim! Why not replace that with:

    
    
        import "code.google.com/p/go.crypto/bcrypt"
    
        User := (... code pulling down the user account by username)
    
        err = bcrypt.CompareHashAndPassword([]byte(user.PasswordHash), []byte(password))
        if err != nil {
            // invalid, password didn't match
        }

~~~
revelation
Also, please don't tell people to write user input sanitation functions to fix
SQL injections. Tell people to use a proper interface to their database that
doesn't mix commands with data.

~~~
tptacek
That is good advice as far as it goes, but even with parameterized queries,
there are "parameters" to queries that can't be "parameterized", and so
sanitization of some sort is usually required. A hobby horse of mine is
reminding people that it's dangerous do rely exclusively on parameterized
queries.

------
cjslep
One thing I've never quite understood is how a lot of Go code (including this
blog post) handles package-level vars. Things like gorilla's
CookieStore/Upgrader or application-specific structs like a hub, database
connection, or websocket pool could conceivably be singleton package-level
vars, and in practice it seems like a lot of small-sized servers implement raw
http.Handlers and just stick to using package vars.

I'm not trying to start a Singleton debate but I like to avoid using them
where possible, so I always wind up writing http.Handler factories moreso than
raw handlers. This comment may be a bit outside of this blog post but I am
curious if package-level vars and raw Handlers are more idiomatic in Go than
using factories to produce handlers and prevent package-level vars.

Edit:

Calls in the original post that made me think of this are calls such as:

    
    
      user.FindUser(usr.Email)
    
      cookies.LoginCookie(usr.Email)
    

...which may very well be package functions instead of struct member
functions.

------
jwcrux
The sql package in the standard library has support for parameterized queries,
so you should use those instead of some random function to check for
injections.

