Re: preserve login from app to app?
Re: preserve login from app to app?
- Subject: Re: preserve login from app to app?
- From: Jonathan Rochkind <email@hidden>
- Date: Tue, 6 Apr 2004 12:14:08 -0500
I worked up my own (rube goldberg-esque) system to do what Greg is
talking about. It worked reasonably well, but lately I've decided the
better approach is not to even _have_ multiple applications, just
have _one_ single application, with a lot of frameworks. So when you
switch to the other functional 'application' (to the user, it seems
like another app), it's really the same WO app, and they can keep
their same session.
But here's the system I worked out, along the lines of what Greg
describes. App1 is the app the user is already logged in to. App2 is
the app you want to link to, and you want the user to navigate to and
still be authenticated.
1. When App1 generates the link to App2 (generally to a direct
action in app2), it adds a bunch of URL key/values on the end of the
URL, to basically specify the hostname, WO app name, instance#, and
sessionID, of the user's session in App1.
2. Now when the Direct Action in App2 gets a request, it checks for
those url key/values. Let's assume it finds them. It now knows that
the user is authenticated in App1, which is located at a supplied
hostname, WO appname, instance #, sessionID, etc.
3. First thing App2 does is make sure the hostname supplied is on a
list of "approved" hostnames. (That is, hosts that we're actually
running apps on that we want to allow the authentication to 'migrate'
from).
4. Assuming that test is passsed, App2 can now construct a URL to a
special purpose direct action in the appropriate session of App1.
App2 uses WOHTTPConnection to send a 'back channel' request to that
DA in App1. That DA in App1 returns XML, which App2 can parse to
find out: "User with userID X is authenticated in this session", and
then App2 can decide that user is authenticated in it's session too.
This worked. And I think it's reasonably secure (the list of
'approved' hosts is important, or an attacker could tell App2 to
'call back' to the hacker's own site!) Although there were some
annoying details and bugs in my own code to work out. In retrospect,
I think there is probably a simpler (and perhaps more secure) way to
do much the same thing, perhaps involving using the database to
communicate, assuming both apps have access to the same database.
(App1 just puts a token in the db, and tells App2 to look for that
token in the db). I am willing to share my code, but it's all
wrapped up with lots of other custom code, and I'm not sure how proud
I am of it in general, so I'm not sure how useful it would be to you.
--Jonathan
On Apr 5, 2004, at 6:20 PM, Greg Smith wrote:
I would like to add a link in one app to go to another app and
preserve the fact that the person has logged in.
Direct Action - it would seem anything I sent with the DA will
compromise the security credentials
Cookies - seems safer but I believe even a session cookie is stored
for a short time. A hacker could look at that cookie and decipher
how I identify and authorize the user. Then substitute to gain
access.
Use a database table - I could store a code indicating user X was
just logged in to app A then when they access app B verify
existence in data base.
These all seem a bit "rube goldberg" to me.
Does anyone know the "right" way to transfer to a second app while
preserving some login and identity knowledge? Thanks.
Greg
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.
_______________________________________________
webobjects-dev mailing list | email@hidden
Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/webobjects-dev
Do not post admin requests to the list. They will be ignored.