Rails - Nov 2009 - PHP/Rails cooperative sessions thought. (read: am I full of shit, or could this work?)

Scenario:  An application X, is a PHP app that''s been running just
fine for quite some time.  An application Y is a new Rails app.
Specifically, a RESTful service.  Y can only be accessed by a user
once that user has successfully authenticated against X.  Y is
accessed immediately following authentication against X.  Y has access
to X''s database.

As far as I know, there seems to be no good way to do this, so the
best idea I can dream up is to have X generate and store a perishable
token for the authenticated user.  Since Y is accessed before a user
can know the value of the perishable token, the token is passed to Y,
where Y then finds the user''s record, and matches the perishable
token.  Pass or fail, the token is immediately removed from the
database.  If the match is successful, Y creates a session for the
user.  If the match fails, the user is redirected back to the login
screen.

Is this total lunacy?  Could this work?  Is there a better way to do
this (i.e. a bit of Rails magic?)  WTF?!

Best Regards,
Tim

On Mon, Nov 9, 2009 at 7:06 PM, Tim Lowrimore
<tlowrimore-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
>
> Scenario:  An application X, is a PHP app that''s been running just
> fine for quite some time.  An application Y is a new Rails app.
> Specifically, a RESTful service.  Y can only be accessed by a user
> once that user has successfully authenticated against X.  Y is
> accessed immediately following authentication against X.  Y has access
> to X''s database.
>
> As far as I know, there seems to be no good way to do this, so the
> best idea I can dream up is to have X generate and store a perishable
> token for the authenticated user.  Since Y is accessed before a user
> can know the value of the perishable token, the token is passed to Y,
> where Y then finds the user''s record, and matches the perishable
> token.  Pass or fail, the token is immediately removed from the
> database.  If the match is successful, Y creates a session for the
> user.  If the match fails, the user is redirected back to the login
> screen.
>
> Is this total lunacy?  Could this work?  Is there a better way to do
> this (i.e. a bit of Rails magic?)  WTF?!
Hey Tim, I had a very very similar scenario a few months ago and I
solved it the way you''re describing here.
My case was a control panel (Rails App) for a quite big PHP
application (which was planned to be moved to rails, but never
happened).
I couldn''t find a better way to do it, I mean, it''s not the
best of
the architectures, so the solution cannot be completly clean.
The perishable token works, and seems secure as long as you validate
correctly on both applications. I think rails'' magic has nothing to do
here since they''re two different applications. You can apply rails
magic on the rails application, but I''m not sure there''s
something
else to do for the applications communication and interaction.

Anyway, I don''t think this is a bad solution, maybe there''s
some
plugin or something that I am not aware of, but I think this approach
is valid.


Cheers.
-- 
Leonardo Mateo.
There''s no place like ~

Leonardo:  Thanks for the swift reply.  I''m happy to hear this is
working for you!

Cheers,
Tim

On Nov 9, 4:25 pm, Leonardo Mateo
<leonardoma...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
wrote:
> On Mon, Nov 9, 2009 at 7:06 PM, Tim Lowrimore
<tlowrim...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> > Scenario:  An application X, is a PHP app that''s been running
just
> > fine for quite some time.  An application Y is a new Rails app.
> > Specifically, a RESTful service.  Y can only be accessed by a user
> > once that user has successfully authenticated against X.  Y is
> > accessed immediately following authentication against X.  Y has access
> > to X''s database.
>
> > As far as I know, there seems to be no good way to do this, so the
> > best idea I can dream up is to have X generate and store a perishable
> > token for the authenticated user.  Since Y is accessed before a user
> > can know the value of the perishable token, the token is passed to Y,
> > where Y then finds the user''s record, and matches the
perishable
> > token.  Pass or fail, the token is immediately removed from the
> > database.  If the match is successful, Y creates a session for the
> > user.  If the match fails, the user is redirected back to the login
> > screen.
>
> > Is this total lunacy?  Could this work?  Is there a better way to do
> > this (i.e. a bit of Rails magic?)  WTF?!
>
> Hey Tim, I had a very very similar scenario a few months ago and I
> solved it the way you''re describing here.
> My case was a control panel (Rails App) for a quite big PHP
> application (which was planned to be moved to rails, but never
> happened).
> I couldn''t find a better way to do it, I mean, it''s not
the best of
> the architectures, so the solution cannot be completly clean.
> The perishable token works, and seems secure as long as you validate
> correctly on both applications. I think rails'' magic has nothing
to do
> here since they''re two different applications. You can apply rails
> magic on the rails application, but I''m not sure there''s
something
> else to do for the applications communication and interaction.
>
> Anyway, I don''t think this is a bad solution, maybe
there''s some
> plugin or something that I am not aware of, but I think this approach
> is valid.
>
> Cheers.
> --
> Leonardo Mateo.
> There''s no place like ~

I''ve also had to do something like this recently and it worked fine
with the perishable token as well. As Leonardo mentioned it''s pretty
secure as long as the validation is there.

On a completely unrelated note:
I posted last week on another topic regarding web services and getting
going trying to work with an exisiting .NET application and Im happy
to say it took me about 3 days to write and publish the web service.
Thanks again to the group for steering me in the right direction. I
was able to show some of the hardcore .net guys that rails can be
"enterprisey" for lack of a better term.

--
Steven Elliott Jr

On Nov 9, 2009, at 5:32 PM, Tim Lowrimore
<tlowrimore-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>
> Leonardo:  Thanks for the swift reply.  I''m happy to hear this is
> working for you!
>
> Cheers,
> Tim
>
> On Nov 9, 4:25 pm, Leonardo Mateo
<leonardoma...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>> On Mon, Nov 9, 2009 at 7:06 PM, Tim Lowrimore
>> <tlowrim...-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org> wrote:
>>
>>> Scenario:  An application X, is a PHP app that''s been
running just
>>> fine for quite some time.  An application Y is a new Rails app.
>>> Specifically, a RESTful service.  Y can only be accessed by a user
>>> once that user has successfully authenticated against X.  Y is
>>> accessed immediately following authentication against X.  Y has
>>> access
>>> to X''s database.
>>
>>> As far as I know, there seems to be no good way to do this, so the
>>> best idea I can dream up is to have X generate and store a
>>> perishable
>>> token for the authenticated user.  Since Y is accessed before a
user
>>> can know the value of the perishable token, the token is passed to
>>> Y,
>>> where Y then finds the user''s record, and matches the
perishable
>>> token.  Pass or fail, the token is immediately removed from the
>>> database.  If the match is successful, Y creates a session for the
>>> user.  If the match fails, the user is redirected back to the login
>>> screen.
>>
>>> Is this total lunacy?  Could this work?  Is there a better way to
do
>>> this (i.e. a bit of Rails magic?)  WTF?!
>>
>> Hey Tim, I had a very very similar scenario a few months ago and I
>> solved it the way you''re describing here.
>> My case was a control panel (Rails App) for a quite big PHP
>> application (which was planned to be moved to rails, but never
>> happened).
>> I couldn''t find a better way to do it, I mean, it''s
not the best of
>> the architectures, so the solution cannot be completly clean.
>> The perishable token works, and seems secure as long as you validate
>> correctly on both applications. I think rails'' magic has
nothing to
>> do
>> here since they''re two different applications. You can apply
rails
>> magic on the rails application, but I''m not sure
there''s something
>> else to do for the applications communication and interaction.
>>
>> Anyway, I don''t think this is a bad solution, maybe
there''s some
>> plugin or something that I am not aware of, but I think this approach
>> is valid.
>>
>> Cheers.
>> --
>> Leonardo Mateo.
>> There''s no place like ~
> >