Re: Can't override CGI parameters

Replies are listed 'Best First'.
Re^2: Can't override CGI parameters by ido50 (Scribe) on Jun 11, 2004 at 14:08 UTC
Okay here it is: * I don't know if it's mod_perl or mod_cgi, 'cause it is not my own server. I just have an account at a certain host. * `$q->delete_all` * What I'm talking about is a simple login form of the like `$q->textfield('username')` and `$q->password_field('password')`. When submitted, I get the values from the previuos invocation. In other words, from the previous time I've submitted the form. * I am not mixing OO and functional CGI calls. If you need to see some code, there's no problem, just tell me. Thanks. ------------------------- Live fat, die young	[reply] [d/l] [select]
Re^3: Can't override CGI parameters by Joost (Canon) on Jun 11, 2004 at 14:22 UTC
Alright, you can check if you're running as a CGI - check $ENV{GATEWAY_INTERFACE} - if it is "CGI/1.1" you're running as a CGI, if it's "CGI-Perl/1.1" you're running under mod_perl. $q->delete_all should remove all values from that query object, so any values that are in it after that, are put in there by you. More likely is that you create a new CGI object after that, which will again be initialized with the posted values. If you are running mod_perl and you are storing values in variables, it's possible that they will keep their value. They CGI object itself should not do that, unless you're not creating a new object for each request. How do you know that the values are the same as the previous request? Ie: how do you show them? Please show some code. "What should it profit a man, if he should win a flame war, yet lose his cool?"	[reply]
Re^4: Can't override CGI parameters by ido50 (Scribe) on Jun 12, 2004 at 12:18 UTC
Okay so $ENV{GATEWAY_INTERFACE} holds CGI/1.1 so it's not mod_perl. Anyway, I'll be a little bit more specific: Since my program is under developement, I'm the only one testing it right now. At first, I've logged in with a certain user account. Then I've logged out and tried to login with another user account. When logging in (After submitting the login form), the program loads the user given by `$q->param('username')` and checks if `$q->param('password')` equals the loaded user's password. When trying to login with another accout, I get the message that the password was incorrect, though I knew that the password submitted was correct, so I added a print statement to see the loaded password that the program was trying to match (Just in case you're wandering, I used Digest::MD5 so I see the digested password). What I saw was that `$q->param('password')` holds the password I've just entered in the form, but `$q->param('username')` ignores the username I've just entered in the form and keeps the old one, so the password do not match. Very strange. For example, let's say that there are two users: 1. username - 'admin', password - 'pass'. 2. username - 'test', password - 'hello'. I login with the first one. All is well. I logout, and fill the login form again, this time, with the info of the 2nd user. I enter 'test' and 'hello', but the program tries to match 'hello' with 'pass'. If I enter 'test' with 'pass', it will succeed and login to the program with 'admin' instead of 'test'. Maybe the problem is with the logout process... The logout process simply deletes the cookie (That holds the session ID) and that's it... ------------------------- Live fat, die young	[reply] [d/l] [select]
Re^3: Can't override CGI parameters by jdtoronto (Prior) on Jun 11, 2004 at 14:18 UTC
1.. Find out what environment you are in, if it is a shared server then it is unlikely you are using mod_perl. To test what you have - telnet to the server on port 80, then issue the command: HEAD / HTTP/1.0 The server will respond telling you what the Apache was compiled with. How do you know it is from a previous invocation? It could be the 'password manager' in the browser. Try two invocations from totally separate browsers (on the same machine and then on different machines). If that doesn't clear the problem - show us some code - as somebody asked for earlier. We are good, be we aren't phsycic. jdtoronto	[reply]