Skip to content
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

Closed
wants to merge 18 commits into from

Conversation

Ryman
Copy link
Member

@Ryman Ryman commented Aug 27, 2015

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 check cookies_example allows using non-encrypted cookies without any of the setup involving the datatype. It also provides a decent default implementation for the KeyProvider 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 the res.cookies() and never getting a result (as I should have been checking the inbound cookies on req). I had considered blocking the find functionality for the Response's CookieJar, but I can imagine that it may be a requirement for some middleware to re-write an outgoing cookie for some reason. Perhaps res.cookies_out() and req.cookies_in()? It would really have been nice if find just fell through from the outgoing cookies to the incoming (new cookies override) but that might be unexpected by users.

@Ryman
Copy link
Member Author

Ryman commented Aug 27, 2015

(updated GitCop to 100 char lines like our commit convention actually says)

@Ryman Ryman force-pushed the return_of_the_session branch 2 times, most recently from 37804ab to 66ed342 Compare August 27, 2015 13:22
@dariusc93
Copy link

Hopefully it gets pulled soon so i can stop using my small hack to use cookies and sessions in nickel

@Ryman
Copy link
Member Author

Ryman commented Aug 30, 2015

@dariusc93 Any implementation concerns?

@dariusc93
Copy link

@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>
}
```
@Ryman Ryman force-pushed the return_of_the_session branch 2 times, most recently from 858dadb to 9f96bdf Compare September 7, 2015 16:24
@Ryman
Copy link
Member Author

Ryman commented Sep 7, 2015

(rebased)

@Ryman
Copy link
Member Author

Ryman commented Sep 9, 2015

Closing in favor of #280

@Ryman Ryman closed this Sep 9, 2015
homu added a commit that referenced this pull request Sep 10, 2015
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
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants