[2.3.2] Always unauthorized using sessionToken from user (request.user)

[r-whites]

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

[natanrolnik]

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

[r-whites]

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

[oliverchoy]

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

[AlexCW]

Also having the same problem after upgrading this morning.

[flovilmart]

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

[johanarnor]

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

[flovilmart]

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.

[johanarnor]

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.

[johanarnor]

This is now solved!

Saw this issue #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 e788d49

[flovilmart]

so @johanarnor everything works for you?

[johanarnor]

@flovilmart yes!

[flovilmart]

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?

[artonragsdale]

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!

[steven-supersolid]

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?

[artonragsdale]

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.