magento2: Can not access Web Setup Wizard with 2.1 clean install

Solution for me was: Base URLs (Secure) -> Use Secure URLs on Storefront -> Yes -> Use Secure URLs in Admin -> Yes -> Enable HTTP Strict Transport Security (HSTS) -> Yes -> Upgrade Insecure Requests -> Yes php bin/magento cache:clean https://yadi.sk/i/iPJi4k7X3S86Za I SOLVE THIS.

Fresh install on Debian with PHP7.1 and Magento CE 2.2.1. Same result. Cache Management, Backups, and Index Management are the only options under the Tools menu. We’ve delayed over a year upgrading out of Magento 1.9.X because of this issue and the product is still not usable. There’s no way that we’ll ever spend the money to upgrade to be a paid customer when the codebase is this bad for this long.

I am utterly confused by this problem. Magento has its reputation as being one of the top shop solutions on the market, yet here we have an issue first reported months ago, not solved, no clear answer by the developers, and with no proper solution.
I’m just trying to set up a shop for my client, adhered strictly to the installation manual, even using the default nginx configuration file, but installing extensions doesn’t seem to be possible.

What on earth is going on? Is there a fix planned? Is this a bug at all, or do I just have something missing from my configuration? In my whole career as a sysadmin and PHP developer, I’ve never seen something like this - the key functionality of an application is not given yet there exists no documentation, workaround or clear communication.

This is a copy of #4159 what was reopened. Thanks for reporting, closed as copy

absolute rubbish.

Composer is NOT required for magento to work and any developer that would make it a requirement needs to be taken out and shot 😃

Any person who wants to have their own estore for a small shop, will not have the budget to pay for a dedicated server where they can have comoser setup. Most of them use shared hosting.

From: Mo [mailto:notifications@github.com] Sent: Wednesday, May 3, 2017 12:51 PM To: magento/magento2 Cc: rgjoyce; Mention Subject: Re: [magento/magento2] Can not access Web Setup Wizard with 2.1 clean install (#5247)

@rgjoyce https://github.com/rgjoyce Composer should be available for Magento to work - if it isn’t installed yet, just follow the instructions here https://getcomposer.org/download/ . Olga is right, installing extensions using the Magento CLI application seems to work properly.

@buskamuza https://github.com/buskamuza is there a command to update to the latest version automatically? The docs only contain instructions to use composer require …, but having something like bin/magento update [–version:<version>] would be great.

— You are receiving this because you were mentioned. Reply to this email directly, view https://github.com/magento/magento2/issues/5247#issuecomment-298835161 it on GitHub, or mute https://github.com/notifications/unsubscribe-auth/AFMGLJV-EWp0ZqSmEByfRrKY4eDLFQGiks5r2CPbgaJpZM4I-SfM the thread. https://github.com/notifications/beacon/AFMGLE6Aw6iLiaudVG1eVtyGXlXtkIEuks5r2CPbgaJpZM4I-SfM.gif

This is an expected result if you use pub as your Magento docroot; it’s designed this way so you cannot run the Web Setup Wizard in a production environment. Try setting the docroot to the Magento install directory and you should see the wizard again.

I will be out of the office from May 4 and returning May 14.

Please send your inquiries to sales@roselandtech.ca during this period

This is getting lame, 2.2.3 same problem —> websetup wizard goes to /unlogin and gives a 401 authorization error.

PHP71 Appache/Nginx Root not in PUB

Tried sollution:

Solution for me was: Base URLs (Secure) -> Use Secure URLs on Storefront -> Yes -> Use Secure URLs in Admin -> Yes -> Enable HTTP Strict Transport Security (HSTS) -> Yes -> Upgrade Insecure Requests -> Yes php bin/magento cache:clean

Did not work for me!

Its great that you fixed it but if I can’t upgrade the fix doesn’t do me any good…

@rgjoyce didnt work for me. And hopefully nobody really deleted /var, but <installdir>var/ … 😃

Try entering “setup/” into the addressbar manually. In my case the admin cookie is lost between step 2 and 3

What worked for me…

ln -s [magento-install-dir]/setup [magento-install-dir]/pub/setup

After installing mods/updates, remove the link

rm [magento-install-dir]/pub/setup

If the symbolic link doesn’t work for you, check permissions and ownership(mine was set to nobody - the apache.http user)

chown [magento-user]:[magento-user] [magento-install-dir]/setup/*

Hope this helps!

@korostii I don’t think this is in magento team’s list of priorities, and even if eventually fixed by the time that happens do we even need a setup wizard? I find it easier to just use the cli for such things.

@rbostan, thank you for your report. The issue is already fixed in develop branch, 2.2.0, 2.1.9

Ran into this issue, tried various versions up to 2.1.7 (with various methods: Composer metapackage vs. download, etc.). The behavior is always the same: Everything works, except when I click on the Composer > Tools > Setup Wizard link, I get forwarded to setup/index.php/session/unlogin .

Except, on the same server (Apache/2.4.25 on a Linux server, tested with both PHP 5.6.28 and 7.0.20 ), I have one (old) 2.0.0 install where the Setup Wizard is reachable (that one does not sync, but I assume that may be because of old bugs).

Maybe this helps to debug:

On the (old) install where the setup wizard is accessible:

• When I login the admin, a session cookie “admin” is set with the “cookie path” being the admin path.
• When the redirect happens, a NEW additional session cookie is set, again named “admin”, with the “cookie path” being “/setup”.

On the installs where the setup wizard is inaccessible:

• When I login the admin, a session cookie “admin” is set with the “cookie path” being the admin path.
• No additional cookie is set when the redirect happens.

So, it is not so surprising that the setup thinks I am not logged in, as it cannot see the session cookie? The question is why the additional cookie is not set, and/or why the cookie path is not “/” (for an installation in docroot).

@che2on This is based on memory but look for hidden files in the var directory. If there was a real or imaginary error during upgrade, I think there might be a file named .upgrade_err or something. Try renaming it or deleting it.