search

magento / magento2

Prior to making any Submission(s), you must sign an Adobe Contributor License Agreement, available here at: https://opensource.adobe.com/cla.html. All Submissions you make to Adobe Inc. and its affiliates, assigns and subsidiaries (collectively “Adobe”) are subject to the terms of the Adobe Contributor License Agreement.
http://www.magento.com
Open Software License 3.0
11.5k stars 9.31k forks source link

User redirected to account page when trying to checkout #12119

Closed mattcoz closed 6 years ago

mattcoz commented 6 years ago

Preconditions

  1. Magento 2.2
  2. PHP 7.0.10

Steps to reproduce

  1. Log in
  2. Add item to cart
  3. Go to checkout

Expected result

  1. Able to proceed through checkout

Actual result

  1. User is redirected to account page

The cause seems to be a "401 Unauthorized" response to /rest/default/V1/carts/mine/estimate-shipping-methods-by-address-id

mattcoz commented 6 years ago

I wrote a plugin to debug the parameters and result of the isAllowed function of PolicyInterface, here is what I got:

[2017-11-08 21:15:18] main.DEBUG: beforeIsAllowed: null, "self", null. [] []
[2017-11-08 21:15:18] main.DEBUG: afterIsAllowed: false. [] []

Does this help?

mattcoz commented 6 years ago

I've tried disabling all custom modules and third party modules, still get the same behavior.

magento-engcom-team commented 6 years ago

@mattcoz, thank you for your report. We were not able to reproduce this issue by following the steps you provided. If you'd like to update it, please reopen the issue. We tested the issue on 2.3.0-dev, 2.1.10, 2.2.1

cotardo18 commented 6 years ago

hi @mattcoz , could you fix the issue?

mattcoz commented 6 years ago

I'm getting back to this now, still get the same behavior after updating to 2.2.2

mattcoz commented 6 years ago

I extended my debugging and found that the current user is not being picked up in the user context, the user id is 0 and the user type is GUEST.

mattcoz commented 6 years ago

I think I fixed it, the session was getting screwed up in one line of my code that seemed to be completely unrelated. So you can leave this closed.

sambolek commented 6 years ago

Hi @mattcoz - could you please provide an example of how your code was screwing up sessions? We're experiencing the same issue (from what I can see, there are others as well), so interested to see if this can be related to some part of 3rd party/custom code, as we have no errors logged anywhere, but customers get logged out constantly.

jrocchiasasdesmelie commented 6 years ago

Hi @mattcoz - same problem here. could you help us please ? :smile:

mattcoz commented 6 years ago

I was calling session_start() before the bootstrap code in order to check a session variable. I think because the session was already initialized that Magento was bypassing some of its initialization code. I added a call to session_abort() after I was done with it and the problem went away.

https://github.com/magento/magento2/blob/4d4e88a89c5fa525c5ac442a1169ec71d7f8dda0/lib/internal/Magento/Framework/Session/SessionManager.php#L169

sambolek commented 6 years ago

Thanks Matt, that was very helpful.

It turned out to be an issue with one of the Mirasvit extensions (Rewards) that was checking/modifying sessions too early (on controller_action_predispatch event).

lennartbee commented 6 years ago

@sambolek we are having the same issue and we are using the Mirasvit Rewards module. The only controller_action_predispatch event I can find in the Mirasvit Module is in checkout_onepage_success. Could you please specify which file you edited?

lennartbee commented 6 years ago

I found it already, in our case it wasn't caused by the Mirasvit module. https://github.com/magento/magento2/commit/f82a17507acfa821e2bea543a99f072e1de1252f fixed it for us.

antbates91 commented 6 years ago

@magento-engcom-team I can replicate this on 2.2.2, this issue should be reopened.

It does appear to only happen on a few occasions, probably 1 in 10 times but it is an issue.

Preconditions

  1. Magento 2.2
  2. PHP 7.0.10

Steps to reproduce

  1. Log in
  2. Add item to cart
  3. Go to checkout
  4. If the checkout loads, empty the basket, sign out and repeat steps 1 -> 3 again.

Expected result

  1. Able to proceed through checkout

Actual result

  1. User is redirected to account page
akios111 commented 5 years ago

I was calling session_start() before the bootstrap code in order to check a session variable. I think because the session was already initialized that Magento was bypassing some of its initialization code. I added a call to session_abort() after I was done with it and the problem went away.

magento2/lib/internal/Magento/Framework/Session/SessionManager.php

Line 169 in 4d4e88a

     if (!$this->isSessionExists()) {

Hello,could you please explain what you code you put and where to fix this issue? It's happening to me also

goivvy commented 4 years ago

He had an issue like this and oh boy. It was hard to figure out until I noticed a custom theme file had been edited. Long story short, it's most likely your custom theme or your custom extension. Turn off all custom modules and switch to Luma. Then if it starts working, turn on modules one by one to see which one breaks the site. If they all work fine then it's your custom theme that needs closer inspection. Cheers!

nimbus2300 commented 2 years ago

Hi,

I've just spent the best part of a day debugging an issue with this end-point and I thought I'd share my findings in case it saves anyone else some time.

TL;DR: Caused by a third party social-login plugin that 'logged in' the wrong user (same email address, but wrong store view).

Configuration

The symptoms:

What is happening in the background:

Why this was happening in my store

Summary In my case this is caused by a faulty Google Login account matching mechanism in the version of the Mageplaza Social Login button I was using. After authenticating with Google, it grabbed the incorrect user account (from another store) and set this as the active user. I'm going to upgrade/fix this.