I am working on a gem that will need to read and write to not just to the current session, but to other "linked" sessions. Right now I am hard-coding reads and writes to the underlying session store we are using in our rails and rack apps whenever I need to update a session other than the current one. But, a more generic approach would be needed to make the solution portable to other session implementations.
In Rails apps I can look at Rails.application.config.session_store to determine the session storage implementation, and instantiate a new instance to read and write to sessions beyond the current session. Generating another instance of the session store seems a bit inefficient, but it does seem to work.
However, I can't figure out any way to query the current session store through a Rack app. env['rack.session'] and env['rack.session.options'] don't provide any insight.
The best solution would be to access the already-instantiated Rack::Session Rack app in the middleware stack. I'm not sure how to query what middleware is running and which one is the current Rack::Session implementation (just check which one is a decendent of Rack::Session::Abstract::ID?).
Any tips for querying the middleware or alternative suggestions would be greatly appreciated.
You can access the session in rack using request.cookies["rack.session"]. Rack < 1.0 used to allow you to actually pass session variables in through a request, but it has been disabled in newer versions of rack for security purposes. I know it's kind of late but hopefully this helps you.
Related
I wonder if using codeigniter session is safe.
Some earlier versions said no because the default configuration file was configured in a way that was unsafe.
In the current version (3.1.2), have this problem? Do I need to worry about using encription_key, for example?
Thank you.
Sessions are stored on the server. As long as the server is safe, sessions should be safe as well. CodeIgniter's session class is just a wrapper for PHP's native sessions.
Does anyone know if there's any way to get ColdFusion 10+ to store sessions in dynamoDB using the SDK?
http://docs.aws.amazon.com/AWSSdkDocsJava/latest//DeveloperGuide/java-dg-tomcat-session-manager.html
http://java.awsblog.com/post/Tx12CFK2FZ7PXRN/Amazon-DynamoDB-Session-Manager-for-Apache-Tomcat
AFAIK no, because Session scope can store any variables, whereas dynamoDB is a DB so variables have to be serialized first at least. However, if your new or existing app does not reference session directly and use an abstration layer like Coldbox's SessionStorage then you may still be able to do it, but I will then worry about the latency.
I've a large application working on and I am facing with hte problem of sessions a lot, it just unset or corrupt the session of my application sometime, all I got it undefined in my session.
By the way I need to know is there any alternative of sessions so I came to know after R&D that I may use cookie, but I think these things are same before .
So I am stuck, don't know how to get rid of my problem.
Now I've some questions as I am a beginner
what is the difference b/w sessions and cookie in sailsjs.
how to set and get cookie in sailsjs.
i am using sails version v0.94
Please guide me in this.
Session is a schemaless object that can be saved in memory or a persistent store such as Mongo or Redis. Using a memory store like Redis or Mongo helps to persist your sessions across multiple application servers or during an application restart.
The cookie tracks a user with a specific ID to associate with the session. Sailsjs, on top of Express, manages cookies and sessions automatically. When a user accesses your site it is assigned this cookie that has a unique ID. Then sails/express automatically will associate session information to that particular client based on their unique cookie. Sails does more than express by allowing you to use this with with sockets as well.
This is all done so you don't have to save and update session the same as a normal DB. You just set the property and move on.
The reason not use cookies is if you prefer to keep the information on the client and do not want to create overhead for your server to look for that value in memory or in a DB. You will want to make sure this information does not need to be secure.
To learn how to use cookies you should google "Expressjs Cookies" (remember sails runs on top of express, current version 3.x)
If you want an alternative to sessions / cookies you can look at web tokens http://jwt.io/
Remember sailsjs runs on expressjs if you can't find what your looking for, then always search for an express solution as well.
Say I have some objects that need to be created only once in the application yet accessed from within multiple requests. The objects are immutable. What is the best way to do this?
Store them in the session.
If you don't want to lose them after a server's restart, then use a database (SQLite, which is a single file, for example).
You want to persist your objects. Normally you'd do it with some ORM like Active Record or Datamapper. Depending on what is available to you. If you want something dead simple without migrations and you have access to a MongoDB use mongomapper.
If that object is used only for some time, then it is discarded (and if needed again, then recreated), use some caching mechanism, like memcached or redis.
If setting up such services is heavy and you want to avoid it, and - say - you are using Debian/Ubuntu then save your objects into files (with Marshal-ing) in the /shm device which is practically memory.
If the structure of the data is complex, then go with SQLite as suggested above.
in the last line in the following bug report
https://github.com/grails/grails-core/issues/5296
it is stated that;
In an ideal world, it would be possible to turn off HttpSession creation for a whole Controller (all actions) and also turn them off for a particular set of actions.
This is however, a quite old bugreport, so my question is:
is this possible in an upcoming or todays version (1.3.7) of grails? If not, shouldn't it be?
The reason i seek this kind of behavior is due to development of RESTful API's in grails, where the very nature of REST is stateless.
Grails does not create a session if you do not access the implicit session object or use session-scoped services. We have multiple projects running in production, where we do not use sessions. As long as you don't access those objects, you won't see any sessions (no JSESSIONID cookies being sent with the response).