Unexpected basic auth credentials take precedence over credentials in header or body params

[gyratorycircus]

Make sure these boxes are checked before submitting your issue -- thanks for reporting issues back to Parse Server!

• You've met the prerequisites: https://github.com/ParsePlatform/parse-server/wiki/Parse-Server-Guide#prerequisites.
• You're running the latest version of Parse Server: https://github.com/ParsePlatform/parse-server/releases
• You've searched through existing issues: https://github.com/ParsePlatform/Parse-Server/issues?utf8=%E2%9C%93&q=is%3Aissue Chances are that your issue has been reported or resolved before.
• You have filled out every section below. Issues without sufficient information are more likely to be closed.

Issue Description

This issue came up when investigating of #394 on ParseDashboard, which describes problems when running both ParseDashboard and ParseServer, and requiring basic auth for ParseDashboard.

The overall dashboard basic auth credentials configured in ParseDashboard are being sent via basic auth as one would expect, but the ParseServer middleware is parsing out user as appId and password as masterKey from the basic auth. Subsequently, these credentials are used instead of likely valid appId and masterKey which are in the request body or headers. In this situation, ParseDashboard is not intentionally sending the basic auth credentials to ParseServer, but they're being included by a cookie since both are running on the same server.

As @theill discovered in the above issue discussion, the behavior came about in this commit: ParsePlatform/parse-server@01318e6. Starting at line 34 of middleware.js in this commit, the desired app ID and keys from the headers could have been set on info, but since httpAuth(req) was able to properly parse out user and password from the request, info.appId, info.masterKey, and info.javascriptKey are overwritten. Further down at line 67, the existence of ainfo.masterKey (even non-matching) prevented all parameters from being parsed from the body.

The basic auth support was added to support backwards compatibility in the REST API (#1059) which is great, but since its available as an alternative, the basic auth creds should not taking precedence over valid credentials being sent via the header or body parameters. I’d be inclined to address this in ParseServer to ensure it stays flexible and won't use unknown basic auth.

Steps to reproduce

1. Setup ParseServer and ParseDashboard as express middleware as described here: Run both Server and Dashboard
2. Configured dashboard with user authentication:

var dashboard = new ParseDashboard({
    // Parse Dashboard settings...
    apps: [{
      // App configuration...
    }],
    users: [{
      user: 'admin',
      pass: 'password',
    }]
}, allowInsecureHTTP);

Expected Results

Dashboard is able to connect to Parse Server when run.

Actual Outcome

Dashboard cannot connect due to 403 Forbidden errors.

POST http://localhost:1337/parse/serverInfo 403 (Forbidden)
POST http://localhost:1337/parse/classes/_Installation 403 (Forbidden)
POST http://localhost:1337/parse/classes/_User 403 (Forbidden)

Environment Setup

• Server
  • parse-server version (Be specific! Don't say 'latest'.) : 2.2.17
  • Operating System: OS X 10.11.5
  • Hardware: Retina Macbook Pro
  • Localhost or remote server? (AWS, Heroku, Azure, Digital Ocean, etc): Localhost

[hramos]

Looks like we can close this now that #2574 has landed.