- Remove a test that was obsoleted by optimizations. Not 100% sure this
is correct, but it seems like if nothing has changed since the
previous session/cookie read then we shouldn't need to write any new
headers for them. This is especially true in the typical "I use
cookies for everything" use case, but may not be true of other use
cases... Remains to be seen. Since they're optimizations they should
be able to removed "safely" later.
- Add a ClientStateMiddleware that loads the client state into the
request context and prepares a ClientStateResponseWriter for
downstream handlers
- Clean up some of the handling around session and cookie state, for
example don't write if there are no events to be processed
- Redo the Defaultts() method for config to be useful again.
- Prefix LogoutMethod with Auth to be consistent
- Change changelog format to use keepachangelog standard
- Refactor the config to be made of substructs to help organize all the
pieces
- Add the new interfaces to the configuration
- Clean up module loading (no unnecessary reflection to create new value)
- Change User interface to have a Get/SetPID not E-mail/Username, this
way we don't ever have to refer to one or the other, we just always
assume pid. In the case of Confirm/Recover we'll have to make a GetEmail
or there won't be a way for us to get the e-mail to send to.
- Delete the xsrf nonsense in the core
- Document more things
- Remove module code
- Remove callbacks code
- Remove data makers, flash messages, and context providers in exchange
for middlewares that use context (unwritten)
- Move more implementations (responses, redirector, router) to defaults
package
- Rename key interfaces (again), Storer -> User, StoreLoader ->
ServerStorer (opposite of ClientStateStorer) if this is the last time
I rename these I'll be shocked
- This addresses the problem of having to update multiple times during
one request. It's hard to have a nice interface especially with JWT
because you always end up having to decode the request, encode new
response, write header, then a second write to it comes, and where do
you grab the value from? Often you don't have access to the response
as a "read" structure. So we store it as events instead, and play
those events against the original data right before the response is
written to set the headers.
