Versions:
Tracks: 1.0.43
Ruby: 1.8.5
MySQL: 5.0.17 (mysqld-nt.exe)
production.log pasted after message text.

I am unable to login to tracks under windows.  I have explicitly defined the shebang to my ruby.exe (#g:/ruby/bin/ruby.exe), and I am NOT using any sort of generic, “easy install” of ruby/mysql/etc… (I actually wrote a tutorial on installing tracks to windows, back when I first discovered it.)

I started having this problem in the version I originally used (I can’t remember the number), so I upgraded to 1.0.43.  Then, I wiped the MySQL database (drop database tracks), and re-created it, and re-rean ‘rake migrate’.  I’ve since tried to both create a new account, and I’ve tried with the example data (re-dropping tables, re-running migrate, and load_fixtures).  I’ve verified the existance of data in the database.

This issue appears to be occuring with all Ruby programs.  I’m hoping some of the ruby gurus here can help, or - since this is not neccisarily a tracks problem - direct me to the appropriate place to pose my question.

NOTE: for tracks, in console, assigned pass = “password”, and then ran hash routine Digest::SHA1.hexdigest(“#{SALT}—#{pass}—“) and verified hash output by script is exact match for hash in database.  Apparently the issue is between the time the password is input into the browser, and the time the script processes it.  It is not a browser issue (verified problem exists in FF, Opera, and IE).

The production.log paste is a clean database (only rake migrate).  I first went to /signup, filled in info, and upon hitting button, page went to /login.  I attempted to login, and it refreshed back to login page, displaying no error. (Attempts to login with a non-existant username result in standard error message.)  Just for comparison, I went back to 127.0.0.1:3000 in a fresh tab, and tried to log in with a non-existant user (and received login unsuccessful error).

Thanks!
-Eric
production.log (using code tags to preserve line wrap):

fyre - 26 November 2006 07:08 AM

Processing LoginController#create (for 127.0.0.1 at 2006-11-26 02:01:31) [POST]
  Session ID: e6eddba31824253dabd7b93f7b637e7b
  Parameters: {"user"=>{"password_confirmation"=>"password", "login"=>"eric", "password"=>"password"}, "action"=>"create", "controller"=>"login"}
Redirected to http://127.0.0.1:3000/
Completed in 0.08100 (12 reqs/sec) | DB: 0.06000 (74%) | 302 Found [http://127.0.0.1/login/create] 

Did you notice that the password confirmation and password are different in this signup attempt? You should have received a validation error, but at any rate, the record would not be saved. Did you check that this record existed in your db?

I’m not sure what else to suggest. I don’t have MySQL 5.x or Ruby 1.8.5, so it’s possible it’s an issue with these versions on Windows thta I don’t know about. You could try running the tests:

and see if those work, because they have to access the db (check that you’ve filled in valid database details in the test: stanza of config/database.yml).

Might this discussion help?

bsag…
Whoops.. the password mismatch is because I was changing the password in the output to a generic, instead of the password I was using.  I’ve since editted.  Could you edit your response, please (and I’ll be changing passwords in a couple of places).

Okay… output for rake test:units was:

Output for rake test:functionals was the same thing.

Strange, because I know the script can access it in production mode, as it inserts the admin account created at /signup without a problem.

MySQL is not the issue.  I’ve duplicated the problem using sqlite3.  It’s in the code, somewhere.

-Eric

by “in the code”, I mean somewhere in either Ruby, or Windows.  Since this is occuring in multiple programs.  Tracks is the just only one I’ve tried that has a decent support community.

Hmm…  wait a second, I think I might have figured something out.

Okay, got it.
All of this?  ez-firewall by Compuer Associates.

No joke.

It dawned on me a minute ago, that the firewall loops each and every web page through its “privacy” feature.  Thereby running every single page, etc.. through a specific port on localhost, and doing god knows what to it.  Apparently, ruby didn’t like that.

What’s weird is that I could log in to ruby apps on remote systems, with the firewall running.

I think I need to explicitly define a few things and I should be good to go. =)
Implicit trust of 127.0.0.1 might be a start.

Thanks!
-Eric

Yay! Glad you’ve worked it out (previous reply edited to remove your secrets )