Skip to content

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

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
r-whites opened this issue Jan 18, 2017 · 21 comments
Closed

Comments

@r-whites
Copy link

r-whites commented Jan 18, 2017

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
Copy link
Contributor

natanrolnik commented Jan 18, 2017

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

@r-whites
Copy link
Author

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

@oliverchoy
Copy link

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

@AlexCW
Copy link

AlexCW commented Jan 24, 2017

Also having the same problem after upgrading this morning.

@flovilmart
Copy link
Contributor

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

@johanarnor
Copy link

johanarnor commented Mar 2, 2017

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
Copy link
Contributor

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
Copy link

johanarnor commented Mar 2, 2017

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
Copy link

johanarnor commented Mar 2, 2017

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
Copy link
Contributor

so @johanarnor everything works for you?

@johanarnor
Copy link

@flovilmart yes!

@flovilmart
Copy link
Contributor

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
Copy link

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
Copy link
Contributor

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
Copy link

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.

@johanarnor
Copy link

@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.

@artonragsdale
Copy link

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?

@johanarnor
Copy link

Yes, that sounds right.

@steven-supersolid
Copy link
Contributor

Yes.

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

@CiraciNicolo
Copy link

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

@stale
Copy link

stale bot commented Sep 18, 2018

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.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

9 participants