This is kind of a tricky problem. I have a forum (simplemachines) containing all of the users for my RoR app. The question is, how would I authenticate a user of a foreign app before giving them a session with the RoR app? (It''s not possible in this case to create a new ''user'' table in the rails app) Thanks -- Posted via http://www.ruby-forum.com/.
I''m not familiar with simplemachines in particular, but here are a few options. If you have database access to the simplemachines db and you''re operating in the same domain you should see whatever cookie their system is using to continue their session at simplemachines. Simply verifying this cookie against the SM db would allow you to establish a new session for them in the rails app. Alternatively if you''re operating in a different domain but still have access to the SM db, you could have them authenticate again against this database (or see my next option). Otherwise, if you can modify the SM source you can append an argument to all links which provides a secure key to your rails system. A simple example being a user id for the authenticated user along with an expiration timestamp and a secret key. Hash all of those together to provide some authentication. Basically your generated link URL could be: http://rails.app.com/foo/bar? uid=blah&expire=blah&securehash=feeddeadbeefbaceddeadbeef0 or something along those lines. Since the key is secret an attacker who has not directly sniffed the traffic should not be able to generate a matching hash. Obviously this is not an optimum level of security, but it little worse than a directly authenticated app where cookies are used for session preservation. If none of the above are options, I''m afraid you''ve tapped me for ideas. Hopefully this has provided you with *some* useful inspiration. -- Jon On Dec 24, 2005, at 2:06 AM, Aaron Elbaz wrote:> This is kind of a tricky problem. > > I have a forum (simplemachines) containing all of the users for my RoR > app. The question is, how would I authenticate a user of a foreign app > before giving them a session with the RoR app? > > (It''s not possible in this case to create a new ''user'' table in the > rails app) > > Thanks > > -- > Posted via http://www.ruby-forum.com/. > _______________________________________________ > Rails mailing list > Rails-1W37MKcQCpIf0INCOvqR/iCwEArCW2h5@public.gmane.org > http://lists.rubyonrails.org/mailman/listinfo/rails
You''ve provided me with much inspiration. Thanks! I will have a go at trying to implement this Any other creative ideas also welcome. Jon Olson wrote:> I''m not familiar with simplemachines in particular, but here are a > few options. > > If you have database access to the simplemachines db and you''re > operating in the same domain you should see whatever cookie their > system is using to continue their session at simplemachines. Simply > verifying this cookie against the SM db would allow you to establish > a new session for them in the rails app. > > Alternatively if you''re operating in a different domain but still > have access to the SM db, you could have them authenticate again > against this database (or see my next option). > > Otherwise, if you can modify the SM source you can append an argument > to all links which provides a secure key to your rails system. A > simple example being a user id for the authenticated user along with > an expiration timestamp and a secret key. Hash all of those together > to provide some authentication. Basically your generated link URL > could be: > > http://rails.app.com/foo/bar? > uid=blah&expire=blah&securehash=feeddeadbeefbaceddeadbeef0 > > or something along those lines. Since the key is secret an attacker > who has not directly sniffed the traffic should not be able to > generate a matching hash. Obviously this is not an optimum level of > security, but it little worse than a directly authenticated app where > cookies are used for session preservation. > > If none of the above are options, I''m afraid you''ve tapped me for > ideas. Hopefully this has provided you with *some* useful inspiration. > > -- Jon-- Posted via http://www.ruby-forum.com/.