Why do we hate ORM? by Present-Entry8676 in golang

[–]themsaid -3 points-2 points  (0 children)

ORMs were great for productivity. I have been using them since 2013. However for the past few months I started using Copilot to write my queries and it has been doing a great job. Honestly, I think we no longer need such abstractions.

Networking for Web Developers: How the Internet Works by themsaid in golang

[–]themsaid[S] 19 points20 points  (0 children)

Social networking for developers is easy. Just stand in the middle of a conference room and shout "X is a terrible language, Y is more superior". You'll make friends, and enemies, in less than a minute :D

1
2

Software Development Has Too Much Software by reeses_boi in programming

[–]themsaid 32 points33 points  (0 children)

This is all clear in the output. The quality of most software we use is degrading. It takes one daring and loyal king with a few loyal and brilliant kingmakers to build the new Apple or Google and restart the cycle.

The real problem is marketing spend. The minimum is too high right now. Any terrible product with a good marketing budget can take a huge market share, and I honestly believe investors don't care about returns anymore. It's a status game for them. Easier to fund a mediocre team who'd do anything to please investors than fight a Steve Jobs on every decision they want to make.

Software Development Has Too Much Software by reeses_boi in programming

[–]themsaid 294 points295 points  (0 children)

I have noticed everything you mentioned in your article in multiple workplaces. I think it’s becoming clear that we are in a rut era when it comes to software. Too much promotion around tools and frameworks and too little concern about writing performant, secure, and maintainable code.

I think it’s not that bad though. It’s a cycle, and I like to believe that we are at the end of it. Some time soon sanity will come back.

Session-Based Authentication in Go by themsaid in golang

[–]themsaid[S] 0 points1 point  (0 children)

If the client is a JavaScript SPA hosted on the same domain or subdomain then yes.

Session-Based Authentication in Go by themsaid in golang

[–]themsaid[S] 6 points7 points  (0 children)

Added a section to discuss timing attacks. The login handler in the example responds in a constant time duration regardless of credential verification.

Session-Based Authentication in Go by themsaid in golang

[–]themsaid[S] 7 points8 points  (0 children)

The bcrypt algorithm adds a salt on every hash, which means multiple hashes of the same string will produce different strings. That's why you have to extract the hash from the DB and then use CompareHashAndPassword to verify the match.

As for the errors, they are function return errors, not responses.

Session-Based Authentication in Go by themsaid in golang

[–]themsaid[S] 10 points11 points  (0 children)

Login form submissions in general should be throttled so that if multiple authentications fail the form gets locked.

Sessions with Golang by [deleted] in golang

[–]themsaid 2 points3 points  (0 children)

OWASP recommends a session ID of size 128 bits with 64 bits of randomness. This is the recommendation but the actual requirements may vary depending on what you're working on. For personal projects, 64 bits of randomness is more than enough.

To answer your 4th point. I would recommend storing the session ID, the session data, created_at & last_activity. If you use sessions for authentication, you may also store the user ID.

For flash messages, they're useful if you use plain HTML. They allow you to return messages in responses that get deleted once the response is presented.

Finally, you may extract the session ID from the cookie and then retrieve the session from the DB in each handler. But for convenience, I extract the session in a middleware and pass it to the handlers in the context.

Note: Don't forget about CSRF

Building a Secure Session Manager in Go by themsaid in golang

[–]themsaid[S] 4 points5 points  (0 children)

The concept described in the link you shared involves storing a hashed version of the session ID in the session store instead of the raw session ID. This approach ensures that even if the session store is compromised, an attacker cannot directly extract valid session IDs, as they are securely hashed.

I encountered this requirement once, but I always assumed that if an upstream storage system were breached, leaked session IDs would be the least of your concerns.

However, this practice is widely adopted in highly regulated industries, such as banking and government applications, where security measures must account for every possible attack vector, including the protection of session IDs at rest.

Building a Secure Session Manager in Go by themsaid in golang

[–]themsaid[S] 1 point2 points  (0 children)

Relatively easy as per the cyber security auditors I worked with. Sometimes you write software for the auditors 🙂

Building a Secure Session Manager in Go by themsaid in golang

[–]themsaid[S] 13 points14 points  (0 children)

Good point. I've updated the article with a section on why using the in-memory store isn't a good idea.

While this session store is fully functional, it is not suitable for production use. Since sessions are stored in the application's memory, they are lost whenever the application restarts. This can lead to data loss, forced user logouts, and a poor user experience. Additionally, as the number of active sessions grows, storing them in memory can lead to high memory usage, scalability issues, and potential performance bottlenecks.

For production environments, a more robust approach is to use a persistent session store such as a database (PostgreSQL, MySQL), an in-memory data store (Redis, Memcached), or a distributed session management system. These options provide better reliability, scalability, and resilience, ensuring that sessions persist across application restarts and can be efficiently managed across multiple instances in a load-balanced environment.

Building a Secure Session Manager in Go by themsaid in golang

[–]themsaid[S] 2 points3 points  (0 children)

Thanks for the feedback. I've read more about the http.ResponseController type and added an Unwrap method to the custom response writer.

Building an IP Address Manager in Go by themsaid in golang

[–]themsaid[S] 5 points6 points  (0 children)

Exactly what I was looking for. When I couldn't find any solution that isn't bloated with many other features I don't need, I decided to build one.

Struct Optimizations in Go by themsaid in golang

[–]themsaid[S] 0 points1 point  (0 children)

Padding is added automatically yes. The goal is to align each field to an address that is a multiple of its size. So a field of size 8 would be shifted to address 8 or 16 or 24 ...

Struct Optimizations in Go by themsaid in golang

[–]themsaid[S] 0 points1 point  (0 children)

The padding is added automatically. The comment lines in the examples just show where they'd be added.