Parse-server: [2.3.2] Always unauthorized using sessionToken from user (request.user)

Created on 18 Jan 2017  路  21Comments  路  Source: parse-community/parse-server

Issue Description

My instance of Parse Server always error out with error "ParseError { code: undefined, message: 'unauthorized' }" when using find({sessionToken: }). The session token is retrieved with "request.user.getSessionToken()".

Steps to reproduce

var token = request.user.getSessionToken(); // it is not null
var query = new Parse.Query(MyTable);
query.find({sessionToken: token}).then(function(results) {
...
});

Expected Results

No error

Actual Outcome

ParseError { code: undefined, message: 'unauthorized' }

Environment Setup

  • Server

    • parse-server version (Be specific! Don't say 'latest'.) : 2.3.2
    • Operating System: Ubuntu 14.04 LTS
    • Hardware:
      Architecture: x86_64
      CPU op-mode(s): 32-bit, 64-bit
      Byte Order: Little Endian
      CPU(s): 6
      On-line CPU(s) list: 0-5
      Thread(s) per core: 1
      Core(s) per socket: 1
      Socket(s): 6
      NUMA node(s): 1
      Vendor ID: GenuineIntel
      CPU family: 6
      Model: 63
      Stepping: 2
      CPU MHz: 2499.980
      BogoMIPS: 5001.29
      Hypervisor vendor: KVM
      Virtualization type: full
      L1d cache: 32K
      L1i cache: 32K
      L2 cache: 4096K
      NUMA node0 CPU(s): 0-5
    • Localhost or remote server? (AWS, Heroku, Azure, Digital Ocean, etc): Linode
  • Database

    • MongoDB version: 3.0.8
    • Localhost or remote server? (AWS, mLab, ObjectRocket, Digital Ocean, etc): Local to the same machine
stale

Most helpful comment

javascriptKey is not optional if you are using javascript, e.g. cloud code. It should be safe to omit if you are just connecting to parse-server to perform queries from a REST or .Net client for example.

The change in 2.2.24 is to enforce key security correctly. Previously if any key was omitted then none were checked, which removed the point of having keys and which led to an undesirable workaround of having to specify unused keys if you wanted key security.

You should be able to remove all client keys from config if you want to disable key security, although I've not tried how this works with cloud code.

This change does seem to cause a lot of issues so perhaps the documentation needs an update?

All 21 comments

@contervis do you have any CLP (Class Level Permissions) configured on this class?

@NatanRolnik The specific class involved in the issue has public READ and WRITE access level.

I have the same problem since I attempted to upgrade yesterday. Last known good version for me (using sessionToken) was 2.2.23.

Also having the same problem after upgrading this morning.

Can you provide the logs when runnjngn with VERBOSE=1?

We are also having this issue. We get the same error when running Parse.User.logInWith('facebook', {authData})

It seems to be an issue introduced in 2.3.0 (actually found out it was probably introduced in 2.2.24). We were previously on 2.2.22

as much as I would like to help, can you please provide the logs when running the server with VERBOSE=1 please? Without it, there isn't much to be done.

Yes, of course, sorry. This is the output when running Parse.User.logInWith('facebook', {authData}):

  express:router dispatching POST /parse/users +6s
  express:router query  : /parse/users +3ms
  express:router expressInit  : /parse/users +2ms
  express:router trim prefix (/parse) from url /parse/users +1ms
  express:router mounted_app /parse : /parse/users +0ms
  express:router dispatching POST /users +6s
  express:router query  : /parse/users +1ms
  express:router expressInit  : /parse/users +0ms
  express:router allowCrossDomain  : /parse/users +1ms
  express:router router  : /parse/users +0ms
  express:router dispatching POST /users +1ms
  express:router urlencodedParser  : /parse/users +0ms
  body-parser:urlencoded content-type "text/plain" +0ms
  body-parser:urlencoded skip parsing +2ms
  express:router router  : /parse/users +2ms
  express:router dispatching POST /users +1ms
  express:router router  : /parse/users +0ms
  express:router dispatching POST /users +0ms
  express:router jsonParser  : /parse/users +1ms
  body-parser:json content-type "text/plain" +2ms
  body-parser:json content-encoding "identity" +1ms
  body-parser:json read body +0ms
  body-parser:json parse body +14ms
  body-parser:json parse json +0ms
  express:router allowCrossDomain  : /parse/users +15ms
  express:router allowMethodOverride  : /parse/users +1ms
  express:router handleParseHeaders  : /parse/users +0ms

Please let me know if you need anything else.
Appreciate the help!

EDIT: tried different versions more thoroughly and discovered that the error first appears in version 2.2.24.

This is now solved!

Saw this issue https://github.com/ParsePlatform/parse-server/issues/3577, and I had done something similar. Previously I had configured my cloud code with 'unused' as the JAVASCRIPT_KEY, but this does not work anymore. So now I supply the configured JAVASCRIPT_KEY in my cloud code. I thought I could leave it empty or null, but that does not seem to work.

I suppose this behaviour was introduced in https://github.com/ParsePlatform/parse-server/commit/e788d49af01b2e1ee09d29ce805300e0875a6322

so @johanarnor everything works for you?

@flovilmart yes!

That's great to hear!

@contervis, I'M not sure if you jumped between 2.2.23 and 2.3.4, but can you try it out?

I can confirm that this does seem to be an error with the logic introduced in e788d49

When I upgrade my project from 2.2.23 to 2.2.24, some cloud code using user.login() and a subsequent user.getSessionToken() breaks and throws the following error: error: Error generating response. ParseError { code: 141, message: '{"message":"unauthorized"}' } code=141, message={"message":"unauthorized"}.

javascriptKey was never configured previously, but when I include it in the new ParseServer() initialization, everything starts working as before the 2.2.24 upgrade.

As far as I know the javascriptKey argument is intended to be optional so this seems to be a bug @flovilmart .

Thanks a ton @johanarnor @contervis and @oliverchoy et all, this was annoying to debug and you guys helped a lot!

javascriptKey is not optional if you are using javascript, e.g. cloud code. It should be safe to omit if you are just connecting to parse-server to perform queries from a REST or .Net client for example.

The change in 2.2.24 is to enforce key security correctly. Previously if any key was omitted then none were checked, which removed the point of having keys and which led to an undesirable workaround of having to specify unused keys if you wanted key security.

You should be able to remove all client keys from config if you want to disable key security, although I've not tried how this works with cloud code.

This change does seem to cause a lot of issues so perhaps the documentation needs an update?

Yeah, I think we should just update the documentation if that's the case, so people are aware that they'll need javascriptKey configured if they plan to use cloud code.

@steven-supersolid @artonragsdale I'm using cloud code and have removed all my client keys from the parse-server config. I using Parse.initialize(process.env.PARSE_SERVER_APPLICATION_ID, null, process.env.PARSE_SERVER_MASTER_KEY) to initialize Parse in cloud code, and it works fine.

I can supply it as well without any affect, so I guess it is just ignored in the request on the server.

So my understanding at this point is

If you want to use cloud code, you can either:
a: use no client keys
or
b: configure javascriptKey if any client keys are in use

You cannot use any client keys without configuring javascriptKey if you want to use cloud code.

Does that sound right?

Yes, that sounds right.

Yes.

And can confirm @johanarnor final point: values for keys that are not configured in the constructor are also ignored.

Let me understand, in this scenario can I continue use the same code just by adding the javascriptKey?

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.

Was this page helpful?
0 / 5 - 0 ratings

Related issues

carjo422 picture carjo422  路  3Comments

darkprgrmmr picture darkprgrmmr  路  4Comments

jaydeep82 picture jaydeep82  路  4Comments

jiawenzhang picture jiawenzhang  路  4Comments

dpaid picture dpaid  路  3Comments