Skip to content

'invalid key name: _ApplicationId' error on signup #246

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Closed
kunalg opened this issue Feb 4, 2016 · 8 comments
Closed

'invalid key name: _ApplicationId' error on signup #246

kunalg opened this issue Feb 4, 2016 · 8 comments
Labels
type:question Support or code-level question

Comments

@kunalg
Copy link

kunalg commented Feb 4, 2016

Updated the parse-server to latest (v2.0.6).
Dropped the DB and created new blank db in Mongo.

From node cli, tried to sign up a new user as described here.

> var Parse = require('parse/node').Parse;
undefined
> Parse.serverURL = 'http://localhost:1337/parse'
'http://localhost:1337/parse'
> Parse.initialize('1', 'abcd');
undefined
> var u = new Parse.User();
undefined
> u.set('username', 'kg');
ParseUser { _objCount: 1, className: '_User' }
> u.set('password', 'kg')
ParseUser { _objCount: 1, className: '_User' }
> p = u.signUp();
ParsePromise {
  _resolved: false,
  _rejected: false,
  _resolvedCallbacks: [],
  _rejectedCallbacks: [] }
> p
ParsePromise {
  _resolved: false,
  _rejected: true,
  _resolvedCallbacks: [],
  _rejectedCallbacks: [],
  _error: ParseError { code: 105, message: 'invalid key name: _ApplicationId' } }

So far, I've been using this same setup successfully till v2.0.4 of parse-server.

Creating the user object using REST API with curl works properly. Then, the same Node.js cli process is able to login the user successfully.

curl -vvvv \
    -H "X-Parse-Application-Id: 1" \
    -H "X-Parse-Master-Key: 1" \
    -X POST \
    -d '{"username": "kg", "password": "kg"}' \
    'http://localhost:1337/parse/users'

* Hostname was NOT found in DNS cache
*   Trying ::1...
* Connected to localhost (::1) port 1337 (#0)
> POST /parse/users HTTP/1.1
> User-Agent: curl/7.35.0
> Host: localhost:1337
> Accept: */*
> X-Parse-Application-Id: 1
> X-Parse-Master-Key: 1
> Content-Length: 36
> Content-Type: application/x-www-form-urlencoded
> 
* upload completely sent off: 36 out of 36 bytes
< HTTP/1.1 201 Created
< X-Powered-By: Express
< Access-Control-Allow-Origin: *
< Access-Control-Allow-Methods: GET,PUT,POST,DELETE,OPTIONS
< Access-Control-Allow-Headers: *
< Location: http://localhost:1337/parse/users/wJykcCCKo4
< Content-Type: application/json
< Content-Length: 116
< Date: Thu, 04 Feb 2016 18:40:04 GMT
< Connection: keep-alive
< 
* Connection #0 to host localhost left intact
{"objectId":"wJykcCCKo4","createdAt":"2016-02-04T18:40:04.068Z","sessionToken":"r:f8d907efdf92900acfa67d550ce89a6c"}

login from node cli:

> p = Parse.User.logIn('kg', 'kg');
ParsePromise {
  _resolved: false,
  _rejected: false,
  _resolvedCallbacks: [],
  _rejectedCallbacks: [] }
> p
ParsePromise {
  _resolved: true,
  _rejected: false,
  _resolvedCallbacks: [],
  _rejectedCallbacks: [],
  _result: [ ParseUser { _objCount: 3, className: '_User', id: 'wJykcCCKo4' } ] }

Funnily, the JS sdk does not send the app id and the keys in the HTTP headers (X-Parse-Application-Id, X-Parse-Javascript-Key, X-Parse-Master-Key etc.) like other SDKs - instead, it sends it as part of HTTP body (JSON).

I verified that at least android and .NET/Unity SDKs send the app id and keys via HTTP headers by going through the code on github.

I've not been able to understand the reason for it. Can anyone please explain why the JS sdk behaves differently?

@gfosco
Copy link
Contributor

gfosco commented Feb 4, 2016

It's a pretty common technique in JavaScript projects because ajax requests can't use all of the HTTP methods, so everything goes through POST with a method override. See middlewares.js for the handleParseHeaders method. It should be deleting the _ApplicationId field, and it is covered in tests afaik. Can you get more information, i.e. capture the request sent to the signup endpoint?

@gfosco gfosco changed the title 'invalid key name: _ApplicationId' when using Parse JS SDK (Node.js) - parse-server v2.0.6 'invalid key name: _ApplicationId' error on signup Feb 4, 2016
@kunalg
Copy link
Author

kunalg commented Feb 4, 2016

Attaching the tcpdump output (with -A option) for the request + response.
I was running the parse server behind haproxy at this time.
parse-user-signup.txt

kunalg added a commit to kunalg/parse-server that referenced this issue Feb 4, 2016
If the incoming request has app id specified both in the header AND
the JSON body, then check that both are the same.
Flag the request as invalid if they are not the same.

If the app id is not specified in the headers, then pick it up
from the JSON body.

Signed-off-by: Kunal Gangakhedkar <[email protected]>
@kunalg
Copy link
Author

kunalg commented Feb 4, 2016

See if commit kunalg/parse-server@6d99a1f helps.

I've verified that it works with my setup of Parse JS SDK.

I've been trying to proxy the different standalone node instances running parse-server for different app configs (for multi-tenancy) using HAproxy.
HAProxy doesn't have support to look inside JSON body to extract fields; however, it's very good at handling headers. So, I wrote a lua trigger script that would parse the body and set the corresponding X-Parse-yyy headers and hooked it up in HAProxy before the headers processing step.

That script is not able to modify the body - to remove these fields from incoming JSON :(

If the above commit works for you, let me know - I'll send a PR.
Or you can just merge it as-is - whatever works.

@gfosco
Copy link
Contributor

gfosco commented Feb 4, 2016

Looks like you're posting with a content-type of text/plain instead of application/json. Can you update your content-type header on post?

@kunalg
Copy link
Author

kunalg commented Feb 5, 2016

It's the JS sdk that's posting it - I've not changed anything in the sdk.

@gfosco
Copy link
Contributor

gfosco commented Feb 6, 2016

I see, it is a byproduct of your HAProxy rewriting.... Go ahead and submit a PR to coalesce the application id (but also cover the client keys too) and remove them from the body if they've been set in the headers. 👍

@gfosco gfosco closed this as completed Feb 6, 2016
kunalg added a commit to kunalg/parse-server that referenced this issue Feb 7, 2016
If the incoming request has app id specified both in the header AND
the JSON body, then check that both are the same.
Flag the request as invalid if they are not the same.

If the app id is not specified in the headers, then pick it up
from the JSON body.

Moreover, remove the app config keys (app id, master key, js key,
.net key etc.) from the request body unconditionally - ie. even if those
are specified in the header. This is so that if the proxy fronting the
app is not able these keys from the body.

Signed-off-by: Kunal Gangakhedkar <[email protected]>
kunalg added a commit to kunalg/parse-server that referenced this issue Feb 8, 2016
If the incoming request has app id specified both in the header AND
the JSON body, then check that both are the same.
Flag the request as invalid if they are not the same.

If the app id is not specified in the headers, then pick it up
from the JSON body.

Moreover, remove the app config keys (app id, master key, js key,
.net key etc.) from the request body unconditionally - ie. even if those
are specified in the header. This is so that if the proxy fronting the
app is not able these keys from the body.

Signed-off-by: Kunal Gangakhedkar <[email protected]>
@nitrag
Copy link

nitrag commented Feb 23, 2016

@kunalg did you submit a PR for this? I think I am having the same issue.

@kunalg
Copy link
Author

kunalg commented Feb 23, 2016

@nitrag I did, but it's failing tests - so, it's not gotten accepted :(
See PR #302.

Currently busy with higher priority work. Will work on it when time permits.

@mtrezza mtrezza added type:question Support or code-level question and removed 🔧 troubleshooting labels Jul 11, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
type:question Support or code-level question
Projects
None yet
Development

No branches or pull requests

4 participants