Anyone storing cart or similar without logging in user? Tracking?

we also just store session id and username in a cookie, cookie is marked as secure and http-only stateful-sessions are just horrible

@janvladimirmostert and then? when you get session id and username in an http request, what do you do next?

@orangy server side we extract the username and token from the cookie (typically a mangled GUID with some extra information around it), do a lookup against the DB to see if that “session” token still exists and if it hasn’t expired yet, if not exist or expired, return error 403 in which case the user needs to log in. If that token exists, extract the user or company which can now be sent along to every method. So for a multi tenancy system, you’d extract the user and the user’s company which will then be used to filter data. Permissions is also happening based on this user / company data retreived from the session table

@orangy so this was my use-case two years ago and what I still use for new multi-tenancy systems that requires to work without sessions due to load balancers https://security.stackexchange.com/questions/84860/how-to-build-a-secure-stateless-authentication-system-for-a-client-side-javascri

Thanks, will check it out

Looking for feedback and suggestions

@pawel.barszcz has left the channel

We use guice & dagger. I’m personally a fan of the simplicity of guice, but many of my team members prefer dagger for the compile-time checking (and the “speed”, which i think is very silly for a server process)

@orangy you won't be surprised to learn that we steer very clear of any DI frameworks. Manual constructor injection FTW. 🙂

Why?

@orangy experience :) ... We've been plenty burned by the startup slowness, code bloat, the pulling in of random framework classes all over your code. And that just DI-by-annotation. In many ways, the XML was better - at least it didn't invade your code or discourage code reuse. And don't get me started on spring-boot... :)

Well, you could replace XML with some Kotlin DSL 🙂

I wonder where startup slowness comes form, scanning JARs for annotations?

I imagine so. In my last experience with DI, the auto wiring just decided to start failing without any message. That was the final straw 😀

I am not at all opposed to manual constructor injection, myself. I have used it extensively on personal projects. I have a much harder time selling it at work, though, since people seem to like the “magic”. ¯\_(ツ)_/¯

I am personally anti-magic, though. 🙂

Do you also develop a qsort algo each time you need to sort something? 🙂

Jokes aside, for me it depends on amount of magic. Some magic is ok, but it should be toolable anyway, i.e. find usages, etc

There’s certainly a judgement call to be made, of course. 🙂 If there weren’t our jobs would all be automated!

Magic is fine when it works, when it stops working, then it’s hit your head against the wall time Prefer being able to follow my code using clickthrough

it looks like Play Framework has a github showing how to use dagger ( https://github.com/playframework/play-java-dagger2-example ).. maybe looking at how others work can help...

We worked with integrating dagger2, gradle, kapt and kotlin a month ago. We got it to work in gradle, but IDEA refused to understand that it needed to generated the dagger2 classes before compiling the rest of the code. 😞

But Idea can use Gradle project, what a problem with that, Idea generate or compile nothing, but delegate that to Gradle? The only thing that you should do for idea is just apply "idea" plugin to you Gradle project, to allow Idea see generated build sources (for code navigation, build should work without that)

If you want, I can create sample project tomorrow that uses Kotlin, kapt, Dagger2 or any other annotation processing library.

That would be awesome. We worked at it for a day or so and finally decided to stick with guice because it wasn’t worth our time to figure out dagger2.

If you have idea delegate to gradle always, it definitely slows down the feedback loop, unfortunately

@AutoMagicallyWired @SuperDeepComponentScanEverywhere 🧌