I am building a Rails app that will live in the subdomain of a Symfony 2 app (PHP). They will be used by the same type of users, and so we want them to go back and forth between the apps and ideally only login once.
I've seen some solutions on how to share session between subdomains for the same kind of apps, but no solution for sharing session between Symfony and Rails. Is it possible?
I was particularly intrigued that Rails session_store can use a database backend -- the default is cookie. That makes me wonder if both apps were to use the database backend, would they be able to share the sessions?
What other alternatives can I use to make this work, if it can work?
Sure it is possible, but I don't know how much work you have to put in ;)
The main thing is the Session ID. It all depends on that. You must make both applications use the same session storage, else it's impossible.
It doesn't matter if you store the SessionId in a database, in a file (would be pretty slow) or somewhere else, as long as both applications use it.
As you mentioned, Rails supports sessions inside a database out of the box. There's also another way in Rails: Memchached Storage. It's more or less an own database, which is optimized for fast key-value lookups.
So you should look if there's a Symfony plugin that supports either SessionId in database or in a Memcache Storage.
Have a look here: http://watsonbox.github.com/blog/2012/05/01/sharing-session-between-rails-and-php/
Forgot to mention: Both applications must also use the same SESSION_ID name inside the cookie ;)
Related
I'm writing a mobile app, and would like to have the user sign in once and pretty much be set for life. From the rails side of things, I'm unsure what the best practice is for keeping track of sessions. One possible solution would be to hand out a JWT with a session ID. I would have a session table in the database, which would allow me to revoke sessions. The JWT would not have a built in expiry time.
Another option would be to use the built in rails session, and deal with the cookie on the app side. To me, this seems kind of hacky, and it's probably not a standard use case because sessions aren't included with api-only rails apps by default.
What's the best-practice way of doing this?
I am looking appropriate resources on "how to replicate session (user session in a stateful app) and cached objects (retrieved from an underlying database through transactional operations) of an application server". The app server can preferably Rails or any other popular one which fully supports MVC framework (using ActiveRecord or DataMapper design patterns).
It will be also helpful to know similar thing about Memcached replication internals as well if it supports this kind of replication.
If anyone can further suggest on how to integrate a NoSQL key-value stores to keep session and cached objects generated in an app server like Rails that would another appreciated answer.
My goal is to find out suitable way to replicate an app server instance for performance (either for local users or geo-distributed) and high-availability. Any point-out to current industry practice and available solutions will be much helpful in this regard.
Thanks a lot in advance.
I have an app that is mostly in rails but also uses nodejs for some realtime features, for example, chat. Users log in via Rails and get assigned a session, etc as usual. However, what's the best way to authenticate with nodejs as that same user? For example I would like to prevent users from impersonating one another but login is done on rails right now and messaging is done on nodejs. Rails and nodejs both have access to the same database.
I am using devise and socketio if that matters.
There's a number of ways implementation wise that you could tackle this. The one that jumps to mind is to share the session cookie that devise uses with nodejs via the database.
IIRC devise creates an encrypted session cookie during authentication; save this value temporarily to your database, and let nodejs pop it off the database for its authentication. There's likely some difficulty in accomplishing this (porting some of the devise encryption to nodejs, and the like) but if you're doing a rails/nodejs app, I'm pretty sure you're capable of handling it. :D
The benefit here is that a user can't get between the hand-off to accomplish impersonation.
You could always generate a one-time token for any user passed between rails and node. Much, much easier than re-implementing (and maintaining) the crypto strategy used by devise and rails.
That said, sharing sessions between servers creates a lot of extra work for you and effectively doubles your bug surface area (schema, validations, etc.)
Faye is an awesome project which handles this exact use case, so it's probably worth a look :) http://faye.jcoglan.com/
Ultimately we want single sign-on for two applications, one is a rails app and one .net.
Is there a way login to a rails application using devise and cookie session store, and have a .net read this cookie to determine what user is logged in? We are open to switching session stores if that would help.
We would like to keep all auth in Rails, but use the cookie session to allow or deny access to .net application.
Yes, you definitely can do this.
If the session is stored solely in cookies then all you need to do is parse the cookies like rails does. Take a look at ActionDispatch::Request::Cookies to get a better feel for how rails uses cookies.
If on the other hand you store the session in Memcache, Redis, Mysql (or any other external store) you can get the session id from the cookie then look it up in the external store. This is probably easier and slightly more DRY.
As long as you have access to the session cookies you should be able to mirror the Rails session manipulation code in your .NET application and "share" session. I encourage you to start by reading deeper into how Rails handles session.
If I am using both redis and memcached, does it make sense to still use the built-in session API?
I understand that ruby on rails can easily use memcached using its built-in api's, but I want to use both memcached and redis.
If I have to manually access redis, when do I connect to it, per request?
You can still use the Rails session API with other stores, including Redis and Memcached. The store is just that--the place where the session data is stored. The Rails session API still manages the sessions for you.
You don't mention which contexts you're using Redis and Memcached in (or why you're using both, or how), but I'm guessing you're thinking about session data and caching (based on this earlier question: Rails and caching, is it easy to switch between memcache and redis?)
In either case, there's no real value to not use the APIs that Rails provides, unless you have a particularly distinct use case.
If you absolutely must use both, just tell Rails which storage engine you wish to use for which function.
If you're doing something else, perhaps a bit more information would help people give more useful answers.
In Ruby, you can store your data in any datastore. Not sure if you can use the built-in session API to store to Redis AND memcached for the same session.
If you manually access Redis, just connect to it as few times as possible and use persistent connections, if appropriate, to improve performance.
For PHP and other server-side scripting languages, you might not want to use the built-in session management. Many server-side scripting languages (i.e. PHP) store session information in a temporary directory on the hard disk. Only the session ID is stored in a cookie. An advantage of Redis and memcached is they can avoid disk access and store all session/user information in memory. So, rather than using the built-in session API, just write your own little session API using cookies and interacting with Redis or memcached.