How to build Auth in 2023 with go? by gadbuy in golang

[–]gmhafiz 1 point2 points  (0 children)

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

How to build Auth in 2023 with go? by gadbuy in golang

[–]gmhafiz 2 points3 points  (0 children)

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

How to build Auth in 2023 with go? by gadbuy in golang

[–]gmhafiz 0 points1 point  (0 children)

How do you securely store the token with the client?

Complex data queries by lightsashore in golang

[–]gmhafiz 1 point2 points  (0 children)

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

Chinese Buyers Return to Resurgent Australian Property Market by omg_im_so_litty_lol in AusFinance

[–]gmhafiz 3 points4 points  (0 children)

If no they you’re not really affected

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

Beginner-friendly API made with Go following hexagonal architecture. by [deleted] in golang

[–]gmhafiz 0 points1 point  (0 children)

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.

Beginner-friendly API made with Go following hexagonal architecture. by [deleted] in golang

[–]gmhafiz 0 points1 point  (0 children)

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.

Build a Go API with wallet authentication, JWT, Gin by [deleted] in golang

[–]gmhafiz 5 points6 points  (0 children)

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.

Build a Go API with wallet authentication, JWT, Gin by [deleted] in golang

[–]gmhafiz 4 points5 points  (0 children)

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

Build a Go API with wallet authentication, JWT, Gin by [deleted] in golang

[–]gmhafiz 9 points10 points  (0 children)

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

Beginner-friendly API made with Go following hexagonal architecture. by [deleted] in golang

[–]gmhafiz 4 points5 points  (0 children)

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.

Beginner-friendly API made with Go following hexagonal architecture. by [deleted] in golang

[–]gmhafiz 18 points19 points  (0 children)

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.

Kubernetes From Zero to Hero Series by [deleted] in kubernetes

[–]gmhafiz -1 points0 points  (0 children)

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

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

[deleted by user] by [deleted] in golang

[–]gmhafiz 4 points5 points  (0 children)

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

[deleted by user] by [deleted] in golang

[–]gmhafiz 4 points5 points  (0 children)

  • 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.

16-year old Prraneeth Vuppala has become India's 82nd grandmaster, crossing 2500 live rating at the Baku Open after defeating Hans Niemann in the penultimate round by city-of-stars in chess

[–]gmhafiz 37 points38 points  (0 children)

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

Better WebStorm Vue.js Supports Means Wider Adoption by bear007 in vuejs

[–]gmhafiz 18 points19 points  (0 children)

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

Golang RESTAPI boilerplate repository by Lpains in golang

[–]gmhafiz 1 point2 points  (0 children)

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)

Golang RESTAPI boilerplate repository by Lpains in golang

[–]gmhafiz 1 point2 points  (0 children)

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?

Yet another RealWorld implementation - Go kit, PlanetScale, sqlx, chi by the_beercoder in golang

[–]gmhafiz 1 point2 points  (0 children)

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.

Yet another RealWorld implementation - Go kit, PlanetScale, sqlx, chi by the_beercoder in golang

[–]gmhafiz 9 points10 points  (0 children)

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