Fix login prompt when web server redirect doesn’t work

[vgrichina]

Fixes #297

[mikedotexe]

Opened the link on another computer, and after the authorizing in Wallet the last step is to enter you account name. Then it redirected me to:
http://127.0.0.1:3000/?account_id=mike-exe&public_key=ed25519%3A5euofQcDVc497NwYVwoLXZR1c86BWFcNqc2nzBtsxzfq&all_keys=ed25519%3A9Zyt2YKgSaUHNwFzRQxyGHYt6vFXjdLa4nwKQTaBPiiQ

This site can’t be reached

Which looks pretty broken. This is probably a Wallet issue? I'm not super familiar with this workflow yet, but I'll make an issue in Wallet or shell when I dig in.

[janedegtiareva]

nit: let's start leaving some notes on what testing was done in PRs

[mikedotexe]

ran near login from Computer A, copied link over to Computer B. Computer B brings me to Wallet, I go through the steps, after the very last step I see this:

because the URL generated by the new login flow adds this param:

success_url=http%3A%2F%2F127.0.0.1%3A3000

That is a localhost address and port that was determined to be open and available on Computer A, but we're visiting the link on Computer B.

This PR is a good stop-gap and I support merging it to unblock validators using the current version of near-shell. Sure, the final landing page from Wallet is unsightly, but at least they can return to the command prompt on Computer A and successfully retrieve the private key.

I think the next step is to do what @potatodepaulo suggested and have a prompt for the user. Something like, "Are you logging in from a server with no browser? (default no)"

Then the URL posted would be different, including or excluding where the success_url param goes.

[mikedotexe]

I have added comments. I support this approach as a stop-gap