-
Notifications
You must be signed in to change notification settings - Fork 205
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
Rails like session/flash management for Amber. #138
Conversation
- Adds Cookies Session using new cookies storage - Adds Redis Session storage
9c2167a
to
fcbfeb9
Compare
fcbfeb9
to
893ccae
Compare
@@ -1,4 +1,4 @@ | |||
language: generic | |||
language: crystal |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This should probably be in a different PR. I know Dru was in favor of using docker which was why I used this fix. Crystal Core team also uses docker for their travis tests.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I decided to remove it since the crystal v0.23.1 works on Travis. Redis server was not being installed with the docker option causing the specs for this branch to fail.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I recommend adding the redis service to dockercompose.yml and reenabling docker for running our tests. This will eliminate failures because of differences between environments and gives us finer control of the testing environment.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@drujensen I would not know how to do this. Let me know when you have some time I would like if you can walk me thru this setup.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good. I'd definitely change the expires time though. A session isn't very useful if it expires in 2 hours.
src/amber.cr
Outdated
@session = { | ||
:key => "session_id", | ||
:store => :cookie, | ||
:expires => 2 * 60 * 60, # 2 Hours |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Session should last as long as the browser is open like the other MVC's instead of 2 hours.
def find_entry(key) | ||
super(key.to_s) | ||
end | ||
context.session.set_session |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Writing cookies is expensive time wise, now more than ever due to encryption. We should only save cookies if something has changed.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's iterate over this in a separate PR. On those upcoming PRs the signed and encryption should be addressed as well
@@ -0,0 +1,65 @@ | |||
module Amber::Router::Session | |||
class SessionHash < Hash(String, String) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I like that you utilized this.
b938056
to
825d6de
Compare
8f31748
to
08cc2d4
Compare
html_output = <<-HTML | ||
<form action="/posts" method="post"> | ||
<input type="hidden" name="_csrf" value="#{Amber::Pipe::CSRF.new.token(context)}" /> | ||
<input type="hidden" name="_csrf" value="#{csrf_token}" /> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Like this more.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
will defer to @elorest comments, but I like where this is headed 👍
08cc2d4
to
e9d49a1
Compare
LGTM Please squash the commits before merging. Add tickets for re-enabling cookie optimization and encryption options. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I created a new amber project and scaffolding:
amber new blog -d mysql --deps
cd blog
amber g scaffold post title:string body:text
I updated amber to point to this branch:
branch: ep/session-storage
shards update
I added the config for cookie session to the config/application.cr
Amber::Server.instance.session = {
:key => "blog.session",
:store => :cookie,
:expires => 120,
:secret => "secret"
}
I launched the app and created a new blog post.
The flash message for flash["success"] is not being displayed as expected.
@drujensen the reason that the flash message is not being rendered for the new generated app is that the session pipe needs to come before the flash and csrf pipe, as stated above in the PR description. Currently the # Keep in mind the order of the Pipes. Session hash needs to be populatedd before trying to access the session flash scope, the flash depends of the session.
pipeline :web do
plug Amber::Pipe::Session.new
plug Amber::Pipe::Logger.new
plug Amber::Pipe::Flash.new
plug Amber::Pipe::CSRF.new
end |
@eliasjpr moving the session fixed it. I also tested with redis and everything seems to be working correctly. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Ok we can deal with slow downs and options for encrypted vs signed later. Lets get this merged.
* Adds Session Management - Adds Cookies Session using new cookies storage - Adds Redis Session storage * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management
* Adds Session Management - Adds Cookies Session using new cookies storage - Adds Redis Session storage * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management * fixup! Adds Session Management
Description of the Change
I have used the following amber blog app to test the functionality https://github.com/eliasjpr/blog
The Session
A session store that uses an Amber:Router::Session::Store to store the sessions. This store is most useful if you don't store critical data in your sessions and you don't need them to live for extended periods of time.
This cookie-based session store is the Amber default. It is dramatically faster than the alternatives.
The cookie store used for storage is automatically configured to be the best possible option given your application's configuration.
Sessions typically contain at most a user_id and flash message; both fit within the 4K cookie size limit. A CookieOverflow exception is raised if you attempt to store more than 4K of data.
To configure the session:
Configure the Pipeline
Accessing the session
To store something in the session, just assign it to the key like a hash:
To remove something from the session, assign that key to be nil or use
session.delete(key)
The Flash
The flash is a special part of the session which is cleared with each request. This means that values stored there will only be available on the next request, which is useful for passing error messages etc.
It is accessed in much the same way as the session, as a hash.
Let's use the act of logging out as an example. The controller can send a message which will be displayed to the user on the next request:
Rendering the flash message
If you want a flash value to be carried over to another request, use the keep method:
Flash.now
By default, adding values to the flash will make them available to the next request, but sometimes you may want to access those values in the same request. For example, if the create action fails to save a resource and you render the new template directly, that's not going to result in a new request, but you may still want to display a message using the flash. To do this, you can use flash.now in the same way you use the normal flash.
Possible Drawbacks
Current all sessions are encrypted. It has been proposed to sign and/or only encrypt by passing a config param.