If both apps are on the same box / have access to the same database (e.g. distributed servers), then this is as easy as setting a flag in the database and making sure both apps look for this flag and auto-login as needed.
Otherwise, the first thing that comes to mind is to have a special key generated for the user that’s send between apps to warn said app of an incoming already-logged-in user. This will of course be more complicated in terms of determining a proper “identity token” generation algorithm and keeping the transaction secure.
You can’t share sessions or cookies across sites.
Jason
Gave it a little more thought and yeah, there’s a special step you’ll need
Assumptions:
-
Both web apps are on the same box or have access to the same database server
-
App1 and App2 are treated as seperate entities (not using the same database between them)
-
App1 has its database, App2 has its database, and both can access a third database
the third database will hold login/user information:
table User:
id
name
…
logged_in boolean
logged_in_on datetime (or timestamp, depending on database)
App1 and App2, when a user visits the site will query this table when do the user authentication/authorization. If the user isn’t logged in, or the logged_in_on field is too old (for you to decide), then log the user in and update the fields. Of course, I’m also assuming that logging out of one means logging out of both.
Hope that helps describe what I’m thinking.
Jason
I have a similar problem but my second app is deployed as a subdomain to the first app. However second app is a different app al together with different database and may or may not be deployed on the same box. It’s just that the second app is services.eii.com while the first app is just app.com
Jason,
How will you know that the user is already logged in? You will still
need a way to identify him, so the user must identify himself somehow
in the other app (only username will do then, but still it needs to be
provided (unless the link also sends the username from the other
app)).
Open ID would be of tremendous help but not everyone is using open id.
This is how I am going to solve the problem for app1 and app2.
app1 uses db1
app2 uses db2
and there is also db3. This database db3 will have only one table with four columns: login_id ,key , created_at and updated_at
Let’s say that user1 logs into app1. Once the user is successfully authenticated, a record will be inserted in the table in db3. Now anytime the user switches from app1 to app2 then pass the key along with it. App2 receives the key ‘1234567890’. App2 will access db3 and will try to see if this key exists, if yes then get the userid. Now this userid is logged into app2.
Anytime user is switching the from app1 to app2 then update the column updated_at. Run a cron job that will delete this record when updated_at is more than one hour old.
Also if the user logs out clicking logout link then delete the record from db3.
Sorry, I just realize that I had another seemingly untrue assumption: users get to site1 from site2 and vice-versa. Without this assumption, I can see how this is a very difficult problem. So, then, is this really necessary? If the two sites are to be completely separate from each other, why do you want to keep the login information the same?
You can’t check IP address because those change.
Anything else you check will require the user entering in something, so it might as well just be an unlinked login system (even OpenID, unless there’s some desktop utility to auto-fill such fields, will require the user to enter in the login).
And if you require the user to enter in just the login name, there is a very large security hole by not also requiring password.
So if the sites are related, and one clicks on links on site1 that take you to site2, then my solution will work, passing along a key through GET or POST. Otherwise, if the user manually visits each site, they’ll need to enter in full credentials.
Jason
