I was able to reproduce the issue via the steps below.
In a single browser window, multiple tabs:
- Login to Sitecore
- Open JSS app in Experience Editor (keep tab open)
- Wait for forms auth to timeout (set to 1 minute in web.config)
- In a separate tab, in the same browser window where EE is open, request http://localhost:3000 in connected mode
- See CORS error due to:
Message: Cannot redirect after HTTP headers have been sent.
at System.Web.HttpResponse.Redirect(String url, Boolean endResponse, Boolean permanent)
at Sitecore.Shell.Web.ShellPage.GotoLoginPage(HttpContext httpContext, Boolean returnAfterLogin)
at Sitecore.Shell.Web.ShellPage.IsLoggedIn(Boolean returnAfterLogin)
at Sitecore.Mvc.Pipelines.Request.RequestBegin.EnsureLoggedInForPreview.Process(PipelineArgs args)
... rest omitted for brevity
The CORS error was being thrown by the browser because the 500 error on the server prevents the CORS headers from being sent.
This is a bit of an edge case and something the core platform would need to address. We'll register this as a "known issue" and add it to the docs site FAQs / known issue.
The workaround / solution is to either logout of Sitecore, set EE to preview mode, or browse to localhost:3000 in an incognito window or completely separate browser (e.g. Firefox, Edge).
I'll leave the original answer because the troubleshooting steps are still relevant.
The error messages are indicating that perhaps CORS isn't configured properly. You may need to adjust your Sitcore JSS API key accordingly, here's info on how to do that: https://jss.sitecore.net/docs/getting-started/app-deployment#step-2-api-key
Specifically, the following fields (copied from JSS docs for SEO / long-term reach):
CORS Origins: If you will be using connected mode (quite likely), the APIs will need to support CORS so that your dev server (default:
http://localhost:3000) is allowed to make HTTP calls to the JSS services. For purely local development setup, use
* to allow all origins. In production, only allow specific origins (multiple origins are ;-delimited).
AllowedControllers: Use the value shown below. It is also possible to use
*, but explicitly whitelisting controllers is a best practice. If you use additional custom SSC API controllers, they would need to be added to this list.
Impersonation User: always specify an explicit user. The impersonation user is a Sitecore user whose security context is used to determine the security rights of the JSS app to Sitecore content. Most apps should use
extranet\anonymous, giving them the same security context as any anonymous web user. Note that authenticated users (with valid Sitecore auth cookies) will receive their own security context regardless of this setting; it applies only to anonymous requests.
If that doesn't solve the problem, I would check the Sitecore logs for more detailed error information as the console error is indicating that the server is responding with a 500 status code - meaning something isn't working properly on the Sitecore side.