Server side application skeleton for Go language


(George Calianu) #1

My new project who aim all those who want to write HTML5 web applications.

Basic server side web application with the following functionality:

  • HTTP/HTTPS servers
  • routes and authentication on middleware (use gorilla mux)
  • session management (use gorilla sessions)
  • user management (registration, change and delete user, password recovery by mail)
  • offline fallback page if network fail
  • modular design, can be extended very easy
  • config file in JSON format
  • database generated from file or model (with Mysql Workbench)
  • responsive interface for mobile access, browser back button disabled

An article about this project on DEV.to is here.

Enjoy.


(BB-8) #2

Awesome idea!

Depending on how much you actually want to boilerplate, it might be a useful to instil some best practices, for example out of the box password salting & hashing for the sign up using something like bcrypt.


(Ignacio Gómez) #3

I’ll second that, this thing is storing unhashed and unsalted passwords in plain text. I’d also prefer a better format for configuration.

I’ll be honest, I don’t like it much: it does too little and not well. I think it’s ok as a dummy application for a blog post though, so maybe it’s just an “advertising” thing.


(George Calianu) #4

I will consider this for the next version :slight_smile:

There is no advertising, as you can see the license is GPL. I just considered this base program useful and I shared the idea and the code that maybe can help someone as it helped me.

Not all web applications are internet sites and many of them are, for example, internal company applications. Someone who want to write this kind of applications in Go can skip a lot of work (which does “too little”) and focus on his real tasks. This someone can also improve this free work if he want or prefer a better configuration.


(Ignacio Gómez) #5

You got me wrong. I didn’t mean that you were advertising yourself with this.

What I meant is that though I don’t like it as something I’d encourage people to use (as I got to see it first, or how it was “advertised” to me), it’s probably fine for a blog post showing basics on how to build a quick web application in Go.

As for “too little”, again, I’m not criticizing the amount of things it does but saying that if it does only a couple of things (which is totally fine), it should get those right (plain text passwords are not, even on internal company applications).

Tone gets lost when writing, so I can’t tell if my opinion bothered you or not, but I hope it helped anyways.


(Josh) #6

Not to criticize, but I do want to question the assumption that just because an application is “internal”, we can bypass some of the basic security requirements (salts, hashes, robust authentication, etc).

The physical perimeter is an important one, but can be bypassed and often is. Disgruntled employees are one of the largest risks to any company and are within this perimeter. Also, some “internal” applications may be accessed by employees outside the facility on questionable networks. A VPN would help, but an unlocked laptop unattended is still a problem. In my view, the basics of security are essential regardless of the deployment point. Training helps prevent some of the risks, but so does well designed software.

Feel free to disagree and again I am not trying to criticize your work. I certainly could not do better and I am not an expert or professional in the field by any means. I am just a student trying to move forward in my knowledge and skills. Thank you for your contribution and I hope you continue to move forward as well!


(George Calianu) #7

Well, if i understand right, the main problem claimed until now is that the pasword is stored as plain text (unhashed) in the database. Agree, this can be resolved and could be a future in the next version.

About internal applications but not only, the things are not really so bad. Under a VPN and some usual security solutions, employes from various companies access their internal resources (like shares or whatever), so in this conditions hacking a Linux machine to see some passwords from some database is not really a simple thing. From this reason I didn’t insist (now) on security but functionality, following that to resolve this security issues.

Anyway HTTPS are still available with certificates so until someone won’t hack your database I don’t see to much danger using this. But I’m open to constructive suggestions to improve the idea.


(Ignacio Gómez) #8

See, I wasn’t gonna respond, but trying to justify this makes it worse. Your DB is your users’ last stand against malicious parties, so storing their passwords in plain text is just wrong, no excuses. So “the things are not really so bad” or “I don’t see too much danger using this” are really naive, dangerous and wrong things to say.

And it may be the main problem, but it wasn’t the only one. For instance, seeing this in your main function caught my eye:

// NOTE this will avoid processor overload
runtime.GOMAXPROCS(1)

Do you believe forcing this is on your package’s user is ok? What do you know about their machines to hardcode such a limitation?

Your main file also contains the User, Database and SMTP structs, and the “Adding a simple application” section mentions no model or struct for said application, so it’s plausible that you expect people to create their data, configuration and other stucts in the main file: so much for modular design.

Don’t take this the wrong way, I’m not trying to attack you or your code, just pointing out some things about the package that you chose to make public. As I said before, this is mostly ok as a quick blog post example, but please don’t claim the “Project is ready to work” when it’s clearly not.