-
Notifications
You must be signed in to change notification settings - Fork 157
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Another day, Another session. #272
Conversation
(updated GitCop to 100 char lines like our commit convention actually says) |
37804ab
to
66ed342
Compare
Hopefully it gets pulled soon so i can stop using my small hack to use cookies and sessions in nickel |
@dariusc93 Any implementation concerns? |
@Ryman From my point of view, everythings look good to me. I was concern about how the cookies was implemented but after reviewing everything further, it became understandable, especially since i did overlook a few things. |
This can be used to add some compile time dependencies for Middleware and Plugins. To fix code broken by this, you will need to introduce a type parameter for Request, Response, MiddlewareResult and NickelError. ``` // e.g. This fn foo<'a>(&mut Request, Response<'a>) -> MiddlewareResult<'a> // Should become: fn foo<'a, D>(&mut Request<D>, Response<'a, D>) -> MiddlewareResult<'a, D> ``` You can add bounds to `D` in the above to place compile-time restrictions on the server data (can be used for configuration). BREAKING CHANGE
Also adds `on_send` which can be used to execute code when the Response headers are being sent.
The 1.2 beta has a regression for this kind of code, so being explicit should allow us to compile on all targets.
This can sometimes be required when using some middleware which are predicated on the datatype of the Server. An alternative would be to litter the handler with extra type annotations (which is awkward without type ascription), or to use explicit type-annotated functions as middleware. Example usage: ``` middleware! { |res| <ServerData> // res is of type Response<ServerData> } ```
858dadb
to
9f96bdf
Compare
9f96bdf
to
7b7742c
Compare
(rebased) |
Closing in favor of #280 |
feat(server): shared data between requests and plugins for Response I've ripped out the core from #272 and decided we should just push separate crates for now until the implementation for Session/Cookies has settled. This allows more breaking changes to the session/cookies implementations as we experiment without requiring a load of version bumps to nickel itself. It's more work for us to manage, but should be better for users 👍 I've also added a default type for the typeparam, so breakage in client crates should be minimal (until they start using the dataparam!) and only really affect people who've written library level stuff. r? @cburgdorf @simonpersson
After some back and forth and testing with @cburgdorf's project, this takes an alternative approach from #246 which should cause less dancing with borrowck while maintaining most of the functionality.
I also added some cargo
features
for the crate, which if you checkcookies_example
allows using non-encrypted cookies without any of the setup involving the datatype. It also provides a decent default implementation for theKeyProvider
which will hopefully mean people aren't incentivized to use zerod-keys for convenience when they do want encryption/sessions.I'm a little bit worried about the api for the cookies, as I did waste a bit of time when I was trying to
find
a cookie from within theres.cookies()
and never getting a result (as I should have been checking the inbound cookies onreq
). I had considered blocking thefind
functionality for theResponse
'sCookieJar
, but I can imagine that it may be a requirement for some middleware to re-write an outgoing cookie for some reason. Perhapsres.cookies_out()
andreq.cookies_in()
? It would really have been nice iffind
just fell through from the outgoing cookies to the incoming (new cookies override) but that might be unexpected by users.