-
Notifications
You must be signed in to change notification settings - Fork 203
DRAFT for now (working on https://github.com/volatiletech/authboss/issues/209 and https://github.com/volatiletech/authboss/issues/210).
From: https://github.com/volatiletech/authboss/issues/213#issuecomment-451711356
@aarondl (the real boss):
Session is persisted however you decide it is. The authboss-sample uses the package: https://github.com/volatiletech/authboss-clientstate which implements authboss.ClientStateReadWriter for sessions and cookies. It does this by using the gorilla packages (http://www.gorillatoolkit.org/pkg/). The cookies in the authboss-sample are encrypted before being sent to the client and authenticated on return so they are tamper proof, very secure (except the secret key is public in that repository which makes it very insecure, your own application should not share the secret key just like you don't in rails).
Authboss stores fairly little in the session so using cookies on the client side is fine for this (as long as they're secured properly as noted above). In your application if you're going to be using more session stuff you may want to implement your own authboss.ClientStateReadWriter using redis or files or whatever as a backing store. Gorilla supports file backed stores and the authboss-clientstate repo can take an existing gorilla store so these two libraries can be used to get file storage sessions very easily.
From: https://github.com/volatiletech/authboss/issues/220#issuecomment-453703016
@aarondl (the real boss):
Both make a query. LoadCurrentUser calls CurrentUser under the hood anyway. The difference is the parameters. One takes a **http.Request that's a pointer to a pointer meaning that the original pointer that you're passing in can be modified. This allows it to replace the http.Request with one that has the user loaded into it's request.Context. Which isn't possible with CurrentUser.
It depends on your needs which one you're going to call. The advantage being that LoadCurrentUser caches it in the request. But if you're not a middleware you're the endpoint handler for example then there's no point to calling LoadCurrentUser, just use CurrentUser.