extra query string params in rails

[Bob Carologees]

say i wanted to pass more than an id, i.e. account/some_username/some_password/ in the query string...i would have to set up a new route no? otherwise it comes back with routing error...how come this is the case? i would of thought it would just pass extra elements to the params object by default?

[Stevenwulf]

Hi Bob,

Yes, you will have to setup a new route.

BTW, you probalby shouldn't pass the username or password around in the url.

The reason you need to set up a new route, is so rails can determine where in the parameter hash to place your extra argument. The route that gets used will determine this. In your case you might have something like:

   map.connect 'account/:username/:password',
     :controller => 'account',
     :action => 'some_action'

When this route matches, rails knows to put the url item in the third position into params["password"]


Here is a more in depth explanation:

http://rails.outertrack.com/class/Ac...ing%3A%3ARoute

[Bob Carologees]

cheers. i know its not good to pass sensitive information in the qs - but unfortunately my app has a weird requirement and this seems to be the most efficient solution - only the encrypted password will be passed to the app, not the raw form

[Luke Redpath]

FWIW, if you want to send extra params via GET, you can simply send them using the normal querystring format:

link_to :controller => 'mycontroller', :action => 'myaction', :foo => 'bar'

# becomes:
# /mycontroller/action/?foo=bar

No need for extra routes that way.

[Bob Carologees]

ta luke, i thought there would be something along those lines

[vgarcia]

Why are you putting a password into the URL?

[Bob Carologees]

lol.. im only putting the encrypted password into a url, which is never seen by the user anyway. obviously if someone was sniffing they could find out the encrypted password, then hack the encryption - but at the end of the day if someone is willing to go to that much trouble to hack a site they can just sniff the normal site data anyway as its not https :P the reason? my rails app is using user data from a php forum, when they login i want it to login to the php forum, then the rails app. best way i thought of was to send the login form to the php forum, and then hijack that code to redirect to the rails app if the login was succesful (with the username and encrypted password in the query string to perform a second check ruby side)

[Luke Redpath]

my rails app is using user data from a php forum, when they login i want it to login to the php forum, then the rails app. best way i thought of was to send the login form to the php forum, and then hijack that code to redirect to the rails app if the login was succesful

There must be a better way. Perhaps in your controller you could open up a new HTTP request using ruby's net/http library and send of a POST to the PHP login script using the supplied username/password (which comes from your Rails up from a form POST).

[Bob Carologees]

I've explored most if not all avenues Luke - the problem with the http request is the php forum builds its session data based on a hash which is generated from the ip - if you send an http request the ip received will be that of the server rather than the user, messing up the sessions - with the method you suggest I very nearly had it working, the user was logged in but the hash would not validate when the user subsequently views the forum in their browser hence appearing logged out.

[Luke Redpath]

Which forum are you using? Perhaps you could make a small tweak to the forum source so it generates its hash from an IP address passed as a POST parameter, then you can send the end users IP along with the http request in the controller.

[Bob Carologees]

Vbulletin - yeh it's a possibility. But I checked it out and the code that handles that looked quite convoluted and cropped up in numerous different places and it's the sort of thing where you are bound to end up screwing the login for the actual forum it's self. I'm willing to take this security compromise to minimise the amount of hacking that is needed.

[sweatje]

Seems like maybe you would have better luck "hijacking" the PHP session yourself. You should be able to know the PHP session ID, and since you are running as the sever, even when running Ruby, you should be able to access the file. Parsing the serialized data structure of the session file sounds like it might be less work than what you are contemplating.

[Bob Carologees]

The PHP sessions are stored in the database, do you think that makes it any easier? I must admit I don't quite follow your logic - are you suggest letting the php forum handle the login and just check for the php session instead of a rails session?

[sweatje]

The PHP sessions are stored in the database, do you think that makes it any easier? I must admit I don't quite follow your logic - are you suggest letting the php forum handle the login and just check for the php session instead of a rails session?

Yes, seems like that might be an easier way to handle it. Just find some token inside the PHP sesssion which indicates a) who it is and b) they are logged in, and then just assume you are good with that user in Rails. One other trick is you would have to propogate the PHP session ID in your Rails app also though.

[Bob Carologees]

Thanks - that is a neat solution, I'll definitely try that. In terms of propagating the session ID - I think it would be easier to just set a rails session when the app has determined the user is logged into the php forum - and when logging out this is unset in a similar manner. Obviously it gets more complicated when I worry about having remember me functionality...

[sweatje]

I was actually more worried about what happens when the user tries to go back to the PHP side of your application and gets a new session...

[Bob Carologees]

Hmm good point, I guess the problem will arise if someone logs into the forum and then closes their browser, they'll be logged out of the forum but not the main site. I guess it might be a case of storing the php session id in the rails session and checking whether its still valid on every request :S but that sounds like a bit of an overload.