Currently I have two servers set up, each handling there own thing, but I want to have a unified login between them. Right now one portal's login form is simply sending the username/pass through an API to the Rails portal, and it sends back an auth token, which we then store in our session and use for future authentication and API calls.
So the problem becomes that a user visiting our site has to login once in each portal, since the Ruby API doesn't communicate with ours, and the Ruby side doesn't do anything with the session when the API is pinged but send us back and auth token.
My initial idea was to have the Rails side create the session when we send the credentials to the API, but apparently that won't work as they won't be able to set the session id in the users browser, or at least that's what I was told.
If the Ruby side moved over to using the database for session storage, would that alleviate this issue? Basically, I want to keep most of the changes on the Ruby side for this.
We wound up going a slightly different route. Basically, each side looks for the auth token in the database, and we pass it around via query strings on each link to the other. For example, if the user logs in on the PHP side, the Ruby side receives the username and password via the API, creates an auth token and updates the database, then sends back the token. The PHP side then stores that token in the session and sends it back via query strings (?authToken=blahblah) to the Ruby side, which is always listening for them. If it sees the auth token, it checks the database to make sure there's a match, and if there is, the user is authenticated in the Rails session.
Conversely, the Ruby side's login form simply updates the auth token in the database, and the links that point to the PHP side also pass the auth token. That side does the same check and will authenticate in the case that there is a match.