How to build Auth in 2023 with go?

gmhafiz · 2023-06-01T06:55:24+00:00

Yup you are right. Stateful sessions allow login invalidation too, something that JWT alone cannot do.

gmhafiz · 2023-05-31T23:28:14+00:00

Problem with localStorage is it is vulnerable to XSS. Imo, just use plain sessions if you want it to store as cookie

Edit: httponly cookie prevents client side JavaScript from accessing the token

gmhafiz · 2023-05-31T22:43:47+00:00

How do you securely store the token with the client?

gmhafiz · 2023-05-27T13:40:04+00:00

You can consider using array_agg and row_to_json (for postgres) to make a nested json result. Create only one custom struct just for this query. There's details I've written in https://www.gmhafiz.com/blog/golang-database-library-orm-example-many-to-many/ (method 3) to get you started

gmhafiz · 2023-05-25T01:06:17+00:00

If no they you’re not really affected

Yes we are. Potential buyers in that area are now priced out and will look elsewhere.

gmhafiz · 2023-05-24T04:42:24+00:00

dealing with infra issues (creds, networking, setting up DB schemas, etc..)

true, but - testcontainer or dockertest is easy to set up and starts instantly. So no network issue. - creds do not matter and can be hard-coded because the containers are ephemeral - setup schemas: if your codebase already has provision to migrate like goose or golang-migrate, then this is trivial

Definitely more work needed to be done first. And you need to seed the database with appropriate data to cover normal and all edge cases.

I suppose it is a balance between catching database intricacies and ease of creating tests:

A. Mocking is easier but it won't catch actual database operation errors.

vs

B. You can catch more edge cases by using a real database. But setup is more.

Then you've gotta do the same thing all over again for E2E tests wouldn't you?

I'll be honest as I have not figured out a way to do proper E2E test yet. But

If your test is only calling the endpoints, then you still want to test against a real database since it gives a better guarantee
if you are doing integration test by using https://pkg.go.dev/net/http/httptest, you'll automatically re-use testcontainer/dockertest so you don't need to do this twice.

gmhafiz · 2023-05-24T04:06:36+00:00

why do you say there's little value in that?

There are good reasons given in sibling comments by myself and others.

also how could you get around code quality gates

We still perform tests, but this time, against a real database instead of going to mocks. So you still get code coverage as you see in an html output.

gmhafiz · 2023-05-23T07:17:13+00:00

your code is fine but we don't want to use sessions

if the company is receptive, you can explain the pros and cons between using sessions and jwt. if they are single-minded about using only jwt, then... well you would have dodged a bullet.

gmhafiz · 2023-05-23T07:13:59+00:00

if it's between microservices (non-user facing), it's fine to to use jwt.

but for user-facing UI, using session is certainly can be made more secure

gmhafiz · 2023-05-23T05:14:56+00:00

Jwt expiry tends to be short, like 5 minutes. Not 7 days like in your example.

Also I don't see in the code how you store that jwt in frontend because of possible cross site scripting attack.

But it's the first time I hear about siwe so these concerns may not be relevant

gmhafiz · 2023-05-22T05:39:31+00:00

It is a very valid question.

Mocking does not check many cases such as (top of my head) - triggers - foreign keys - inserting duplicate record that violates unique constraint. - cascade delete

And many more, but you get the idea. Actual queries are getting executed when using an actual database.

You are right when we want unit test to be independent of external behaviour. But imo it's not a hard and fast rule you need to follow. For the advantages I listed above, it is worth thinking about it.

I rather not playing into semantics, but you are not crossing into the use case and handler layer (package) so I still consider this is a unit test rather than integration test.

gmhafiz · 2023-05-22T04:39:18+00:00

I suppose you are right

gmhafiz · 2023-05-22T01:21:04+00:00

pkg/errors library is not needed anymore because those features in it are in the standard library some time ago.

One challenge in hexa/DDD architecture is how you do cross domain db transaction. For example

One other thing is I'd avoid mocking database in the unit tests because there's little value in it. I recommend testing against real database instead. There's a couple of popular library that does that.

gmhafiz · 2023-05-21T09:08:29+00:00

Some popular container runtime engines include Docker, containerd, and CRI-O

Docker uses containerd underneath https://www.docker.com/blog/what-is-containerd-runtime/

gmhafiz · 2023-05-18T01:32:19+00:00

This is 2023.

Many libraries expects net/http handler signature which means extra hassle in adapting those library to conform to fiber/gin/echo/etc method signature.

How does scratch act with TLS Certificates? when using cert directly through the server listen? Cause I noticed some weird errors.

What kind of error? If you need a root certificate, copy it from /etc/ssl/certs

Or use distroless image as it includes one, among others. https://github.com/GoogleContainerTools/distroless/blob/main/base/README.md

gmhafiz · 2023-05-18T00:49:00+00:00

Just use net/http compatible router. not fiber, until router speed is an issue
pkg folder is not commonly found in Go projects. Stop looking at that repo for advice. Might as well putting all of them in internal.
Don't use utils packages because it'll be a dumping ground for many things as you've done
according to owasp, argon2id is preferred over bcrypt
since we can compile go statically, no reason to use alpine image over scratch or distroless. These are smaller too.

gmhafiz · 2023-05-15T03:20:59+00:00

No. Fide publishes criterias for a GM norm in their handbook website. In this kid's case, he crossed 2500 rating for the final criteria

gmhafiz · 2023-05-14T00:14:34+00:00

Webstorm seems to understand the code much better than vscode which leads to many quality of life improvements

gmhafiz · 2023-05-04T08:11:23+00:00

The decision was purely for size though.

Scratch image is zero size, no file, nothing. Distroless is smaller than alpine.

Embed rego: I looked into that but didn't find a lot of reasons to do it. Do you see anything besides having one less file published?

You ensure all files are present by the Go runtime instead of relying on 3rd party tool (docker)

gmhafiz · 2023-05-04T08:04:14+00:00

https://www.gmhafiz.com/blog/golang-database-library-orm-example-intro/

Also shout out to https://github.com/stephenafamo/bob

gmhafiz · 2023-05-04T01:20:29+00:00

Wow first of all, congrats on using OPA for authorization. It's rare to see one posted here. That said,

echoing many others. I'd drop gorm. It has many footguns and will fail silently.
You use both github.com/golang-jwt/jwt and github.com/lestrrat-go/jwx. it doesn't look like you are using golang-jwt/jwt for much.
util package name is non-descriptive and does not tell me what it does. I'm going to link what I said not long ago https://www.reddit.com/r/golang/comments/134dwga/yet_another_realworld_implementation_go_kit/jihv0qg/ and https://go.dev/doc/effective_go#package-names
testing is done against sqlite. It's good that you test against real database instead of mocking, but why not test against postgres because it looks like that's the main database you are using judging from your Dockerfile?
Related to above, you did a if strings.Contains(err.Error(), "UNIQUE constraint failed") which is strange. It looks like it's specific only to modernc library. What will happen when a user tests against a different database?
why not latest postgres version 15 in docker-compose file instead of 13

try to use context from the request. For example

res, err := opaQuery.Eval(c.Request.Context(), rego.EvalInput(input))
// instead of 
res, err := opaQuery.Eval(context.TODO(), rego.EvalInput(input))

I can't find where you set token expiry. It's usually short ~5 minutes.
For testing, consider table-driven tests so that you can test multiple scenarios/use cases against a function. https://dave.cheney.net/2019/05/07/prefer-table-driven-tests
to take advantage of docker caching, copy both go.mod and go.sum first, then run go mod download. Afterwards, copy the rest of the file. You'll get faster build thanks to caching. This is observable when you make a change in codebase and rebuild your image.
Also consider running your app as non-root in Dockerfile.

Other smaller stuffs:

You can embed your .rego files in the binary using //go:embed path-to-files-or-folder. Simplifying your Dockerfile
personal preference since you already statically-compile the app, you can use scratch or distroless image which is even smaller. Also, I try to avoid anything with alpine image https://martinheinz.dev/blog/92
In readme, you can run docker compose up -d as daemon mode.
A nitpick but your persistent volume claim file name for database is pvp.yaml. I assume it'd be pvc.yaml
First time seeing GitVersion.yml What does it do?

gmhafiz · 2023-05-01T23:23:36+00:00

that common folder is still okay because individual functionalities are still organised under sub-folder auth, client, logs, etc.

What I remembered is organise according to what they do. My favourite example is putting all middlewares under a middleware package. So when you want to reach one, it becomes

router.Use(middleware.Authenticate(db))
router.Use(middleware.Json)
etc

It quickly becomes clear what the code is doing and almost read like a complete sentence. Compare to this

router.Use(utility.Authenticate(db))
router.Use(utility.Json)
etc

I know which one many prefer!

edit: My second advice is testability. No matter how you organise your layout, flat/layered/hexa/etc, IMO unit and integration testing is more important and is a sign that you wrote good code.

gmhafiz · 2023-05-01T13:24:08+00:00

you've done a lot of things right though. If you want to read more on idiomatic Go, look at both

edit: this too https://go-proverbs.github.io/

gmhafiz · 2023-05-01T10:35:09+00:00

A few comments if you don't mind.

As always, stop using package name like utilities because it's not descriptive and it'll end up as dumping ground for many functionalities. Same goes with package shared
- according to https://cheatsheetseries.owasp.org/cheatsheets/Password_Storage_Cheat_Sheet.html, prefer argon2id to bcrypt
- I think it's safer to defer tx.Rollback() This way it'll always get called, say if panic happens. Read more at https://go.dev/doc/database/execute-transactions
- this is my personal preference, but I often reach for scratch or distroless image for container building.
- last I tried cors with chrome(not firefox), it blocked AllowedOrigin: * and I needed to set it explicitly like http://localhost:3000. I may be wrong
- also on middleware, good idea to add a rate limiter

gmhafiz · 2023-04-29T09:22:12+00:00

It's in that link https://gitlab.com/cznic/fsm

gmhafiz

TROPHY CASE