3 ms·

Building a Web Server in Go: Handling User Input

15 points by lettergram 12y ago

carbocation 12y ago
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 12y ago
  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 12y ago
    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.
  - wglb 12y ago
    Actually, I do tell them that. The reason is that if you are building a very dynamic web application in which the user's input or existing database values are used, for example, to determine a column name, table name, or even a database name, very strong whitelisting is required. For the other cases, paramaterization can take care of it.
jwcrux 12y ago
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.
cjslep 12y ago
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.

15 points by lettergram 12y ago

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 12y ago
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 12y ago
  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.
- wglb 12y ago
  Actually, I do tell them that. The reason is that if you are building a very dynamic web application in which the user's input or existing database values are used, for example, to determine a column name, table name, or even a database name, very strong whitelisting is required. For the other cases, paramaterization can take care of it.

jwcrux 12y ago

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.

cjslep 12y ago

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.