On heroku shopping cart, user logs in but doesn't redirect properly

[originated]

Running into a issue on heroku, no issues locally. After adding a item to the cart, and then prompted to log in, log in and flash message appears "loged in", and the user is logged in.

Although the screen redirects back to the login screen and doesn't proceed to the next step(address). This works fine on local, what could be the issue? Is there a missing javascript file that didn't compile?!

[originated]

[drhenner]

Sounds like some missing JS but you would most likely have several more issues also if your JS wasn't loading. I have one more week until my broken thumb is out of a cast. Until then I have been limiting my typing.

Curious if this could be a bug if you login as different users on the same machine. hmmm

Until my cast is off keep me up to date. After that I'll see if I can re-produce the bug

[originated]

Yeah, it's very odd. The problem is only happening on production with heroku(fine local). I'm able to add items to the cart, i'm able to checkout, but then it prompts to login. I am able to log in successfully, which appears to be a solid session, but it just refreshes the log in page. The drop menu is fine and I have all the actions of a logged in user, so perhaps something in the logic before entering the shipping address screen? But then again this is fine locally.

Production logs on Heroku point of error:

014-04-09T04:37:57.431578+00:00 app[web.1]: Completed 200 OK in 26ms (Views: 16.7ms | ActiveRecord: 6.0ms) 2014-04-09T04:38:12.028151+00:00 app[web.1]: Started POST "/user_sessions.%23%3CUserSession:0x007fcf89e5b0e0%3E" for 108.0.187.37 at 2014-04-09 04:38:12 +0000 2014-04-09T04:38:12.028151+00:00 app[web.1]: Started POST "/user_sessions.%23%3CUserSession:0x007fcf89e5b0e0%3E" for 108.0.187.37 at 2014-04-09 04:38:12 +0000 2014-04-09T04:38:12.029629+00:00 app[web.1]: Processing by UserSessionsController#create as 2014-04-09T04:38:12.035567+00:00 app[web.1]: Processing by UserSessionsController#create as 2014-04-09T04:38:12.036940+00:00 app[web.1]: Parameters: {"utf8"=>"✓", "authenticity_token"=>"drH5og8/xfCSVs6LxUs+EzseIiR1wmpdXjd1sVWLcGU=", "user_session"=>{"email"=>"test@gmail.com", "password"=>"[FILTERED]"}, "commit"=>"Log In"} 2014-04-09T04:38:12.036993+00:00 app[web.1]: Parameters: {"utf8"=>"✓", "authenticity_token"=>"drH5og8/xfCSVs6LxUs+EzseIiR1wmpdXjd1sVWLcGU=", "user_session"=>{"email"=>"test@gmail.com", "password"=>"[FILTERED]"}, "commit"=>"Log In"} 2014-04-09T04:38:12.110029+00:00 app[web.1]: Redirected to http://www.example.com/shopping/orders 2014-04-09T04:38:12.110075+00:00 app[web.1]: Redirected to http://www.example.com/shopping/orders 2014-04-09T04:38:12.110281+00:00 app[web.1]: Completed 302 Found in 73ms (ActiveRecord: 28.7ms)

Local handling this fine:

tarted POST "/user_sessions.%23%3CUserSession:0x007ffa0a3f1658%3E" for 127.0.0.1 at 2014-04-08 21:40:34 -0700 Processing by UserSessionsController#create as Parameters: {"utf8"=>"✓", "authenticity_token"=>"LhaEnj5TMhqIWLQLmoR8oC1+XG9DfwIFAmZR10F0yRw=", "user_session"=>{"email"=>"test@gmail.com", "password"=>"[FILTERED]"}, "commit"=>"Log In"} User Load (0.7ms) SELECT "users".* FROM "users" WHERE "users"."email" = 'test@gmail.com' ORDER BY "users"."id" ASC LIMIT 1 (0.1ms) BEGIN

As far as I can tell this is happening in the create method in the user_sessions controller. I'm fairly certain this is some issues with sessions

[drhenner]

I'm guessing you dont have memcache setup on heroku correctly On Tuesday, April 8, 2014 9:29 PM, Mike Cifani notifications@github.com wrote:

Yeah, it's very odd. The problem is only happening on production with heroku(fine local). I'm able to add items to the cart, i'm able to checkout, but then it prompts to login. I am able to log in successfully, which appears to be a solid session, but it just refreshes the log in page. The drop menu is fine and I have all the actions of a logged in user, so perhaps something in the logic before entering the shipping address screen? But then again this is fine locally. — Reply to this email directly or view it on GitHub.

[drhenner]

I have not heard back so I can only assume memcached fixed this. I'm closing. reopen if this is an issue still